Bug 984333 - Unlock password dialog sometimes lacks keyboard focus
Unlock password dialog sometimes lacks keyboard focus
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: xmonad (Show other bugs)
22
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Jens Petersen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-14 21:01 EDT by David Gibson
Modified: 2016-07-19 16:19 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 16:19:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xmonad config file (888 bytes, text/x-vhdl)
2015-09-28 21:22 EDT, David Gibson
no flags Details

  None (edit)
Description David Gibson 2013-07-14 21:01:17 EDT
Description of problem:

Sometimes when returning to a MATE session when the screensaver has kicked in, the password box to unlock the screen does not have keyboard focus, and so cannot be completed.  The only way to proceed is to kill mate-screensaver from a VT.

Version-Release number of selected component (if applicable):

mate-screensaver-1.6.0-1.fc19.x86_64

(also observed in Fedora 18)

How reproducible:

Intermittent, no obvious pattern so far.

Steps to Reproduce:
1. Configure screensaver to lock with password
2. Allow screensaver to start
3. Attempt to unlock screen with password

Actual results:

Sometimes, although pressing a key does bring up the password prompt, the prompt does not appear to have keyboard focus and nothing appears when attempting to type password.  Other times it works as expected.

If this happens once, allowing the password prompt to time out (or pressing Cancel with the mouse) then retriggering the password prompt will suffer the same problem.

Expected results:

Password box works, and unlocks screen.

Additional info:

Suspect this may be related to some other windows on the locked desktop which attempt to grab all focus (e.g. VM console from virt-manager) but I don't have confirmation or a clear reproducer yet.
Comment 1 Wolfgang Ulbrich 2013-07-26 05:22:23 EDT
I don't see this issue on baremetal. You're are running MATE in a VM?
Comment 2 David Gibson 2013-07-28 18:19:37 EDT
No, I'm seeing this baremetal on a Thinkpad X230.
Comment 3 Wolfgang Ulbrich 2013-08-18 04:42:31 EDT
Did the issue still exits with mate-screensaver-1.6.1-2.fc19 ?
Comment 4 David Gibson 2013-08-18 20:42:28 EDT
Yes.  Hit it just a minute ago.

voom:~$ rpm -q mate-screensaver
mate-screensaver-1.6.1-2.fc19.x86_64

May be related to the fact I have an unusual windowmanager (xmonad).
Comment 5 Wolfgang Ulbrich 2013-08-19 04:45:13 EDT
(In reply to David Gibson from comment #4)
> Yes.  Hit it just a minute ago.
> 
> voom:~$ rpm -q mate-screensaver
> mate-screensaver-1.6.1-2.fc19.x86_64
> 
> May be related to the fact I have an unusual windowmanager (xmonad).

Is there a reason for using xmonad?
Can you test if the issue exits if you use normal mate-window-manager (marco) in mate?
Comment 6 David Gibson 2013-08-19 20:55:10 EDT
Well, because I'm far more productive with xmonad.  I'll see what I can do about testing with marco - since the problem doesn't hit every time, it will be a bit awkward.
Comment 7 Wolfgang Ulbrich 2013-09-12 15:18:39 EDT
any news?
Comment 8 David Gibson 2013-09-12 21:53:27 EDT
No, haven't had a chance to test with marco.  I still hit the bug multiple times every day.
Comment 10 David Gibson 2013-10-24 19:54:23 EDT
Alas, it does not.
Comment 11 Jens Petersen 2013-11-25 23:31:47 EST
How often does it happen?  (eg how many times out of 10 say?
and what kind of timeframe?)

Can it be reproduced by manually locking the screen?
Comment 12 Jens Petersen 2013-11-25 23:34:51 EST
(In reply to David Gibson from comment #0)
> Suspect this may be related to some other windows on the locked desktop
> which attempt to grab all focus (e.g. VM console from virt-manager) but I
> don't have confirmation or a clear reproducer yet.

Does killing virt-manager say instead of mate-screensaver help?
Comment 13 David Gibson 2013-12-05 21:47:03 EST
I just got a chance to try, and no it doesn't help.  I'm actually pretty sure I've hit this problem without virt-manager running anyway, so I no longer think that's a good theory.  However I think it may have something to do with workrave.  I'll try killing that instead of the screensaver when it next happens.

I haven't been able to reproduce by manually locking the screen.
Comment 14 Fedora End Of Life 2015-01-09 13:55:04 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 15 David Gibson 2015-01-19 23:27:48 EST
I've seen this at least once in Fedora 21.  Updating version.

mate-screensaver-1.8.1-1.fc21.x86_64
Comment 16 Wolfgang Ulbrich 2015-09-24 09:38:49 EDT
(In reply to David Gibson from comment #15)
> I've seen this at least once in Fedora 21.  Updating version.
> 
> mate-screensaver-1.8.1-1.fc21.x86_64

Is this still a problem with mate-screensaver-1.10.x
Comment 17 David Gibson 2015-09-24 21:36:04 EDT
Yes, I'm still seeing this quite often with Fedora 22 and mate-screensaver-1.10.2-1.fc22.x86_64.  I'd say it happens maybe 60-70% of the times the screensaver activates.
Comment 18 Wolfgang Ulbrich 2015-09-25 07:27:38 EDT
I forward it to upstream
https://github.com/mate-desktop/mate-screensaver/issues/82
Can you please comment there for getting notification if upstream has a question?

Btw. How can i install xnomad session to reproduce it?
Comment 19 David Gibson 2015-09-28 21:21:52 EDT
I believe you can install the xmonad-mate package (I currently have xmonad-mate-0.11-13.fc22.x86_64 installed), then select the xmonad/mate session from the gdm menu.

I'll attach by xmonad.hs config file, although I don't know if that is relevant.
Comment 20 David Gibson 2015-09-28 21:22 EDT
Created attachment 1078092 [details]
xmonad config file
Comment 21 Wolfgang Ulbrich 2015-10-01 08:20:50 EDT
Installing xmonad isn't user friendly.
Why are the 2 needed yum/dnf groups in comps unvisible?
Anyways, it runs in a f21 VM now.
But i couldn't reproduce the issue until yet.
So, some more questions: 
Does it only happens if the session is looked?
Do i need to wait longer, ie 2 hours or 6 hours, before i try to unlock the session?
Does it happens when the box boot from hibernate/suspend state?

I tested it also on bare metal several times, no luck.
Which graphic are you using?
I tested it with nvidia driver from rpmfusion.
But sorry, i can't use xmonad on my main box whole the day for testing more ;)
But it seems you're not alone, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785739

PS: you can try out latest mate-screensaver build which have improvements for systemd-login.
https://bodhi.fedoraproject.org/updates/FEDORA-2015-5b345be5b9
Comment 22 David Gibson 2015-10-01 19:52:14 EDT
> Installing xmonad isn't user friendly.
> Why are the 2 needed yum/dnf groups in comps unvisible?

I can't answer that.

> Anyways, it runs in a f21 VM now.

Ok, as noted above, I'm still seeing the problem with f22.

> But i couldn't reproduce the issue until yet.
> So, some more questions: 
> Does it only happens if the session is looked?

Sorry, I don't understand that question.

> Do i need to wait longer, ie 2 hours or 6 hours, before i try to unlock the session?

No, I've rarely left the session locked that long, and I've frequently hit the problem when it has only been locked for seconds.

> Does it happens when the box boot from hibernate/suspend state?

When I resume from suspend-to-ram, I think the problem has sometimes happened, but certainly not more frequently than any other time.

I'm not regularly using hibernate at the moment, so I don't know about that.

> I tested it also on bare metal several times, no luck.
> Which graphic are you using?

I'm using Intel Graphics on a Thinkpad T520.

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

I also encountered the problem on my previous laptop, which was a Thinkpad X230, also with Intel graphics.

> I tested it with nvidia driver from rpmfusion.

I don't have any nvidia machines I could cross test with.


Another thought occurred to me: I also have workrave installed.  I don't know if it is relevant, but it's possible.  Often mate-screensaver activates when I am taking a workrave enforced rest break.  I'm pretty sure I've had this problem occur other times as well, but I'm not certain.
Comment 23 Wolfgang Ulbrich 2015-10-03 13:36:20 EDT
(In reply to David Gibson from comment #22)
> Ok, as noted above, I'm still seeing the problem with f22.
> 
For some reasons xmonad-mate didn't start in my f22 VM.
> Another thought occurred to me: I also have workrave installed.  I don't
> know if it is relevant, but it's possible.  Often mate-screensaver activates
> when I am taking a workrave enforced rest break.  I'm pretty sure I've had
> this problem occur other times as well, but I'm not certain.

After installing xmonad-mate on my notebook MSI FX600 with intel graphic i could reproduce the issue after a long day of testing.
Late in evenning i couldn't unlock the session anymore.
Running 'journlctl -b 0 -f --no-tail' shows me that the fprintd.service was running.
This is complete weird/bad because my notebook doesn't have a fingerprint-reader.
After stoping the service i could unlock the session :)

fprintd.service is a static service wich will call by another service if needed, so i tried to mask the service.
But today i run in the issue again, so masking the service isn't enough.
Dbus tried to load the mask service, which failed of course.
But the lookscreen was unselectable again.
Reason enough to uninstall unneeded fprintd.
Now the lookscreen works until yet.

So the question is why is fprintd.service running on a system w/o a hardware for it, and which other service or appliction call it?

Looks for me more like a fprintd or maybe a systemd issue.

Can confirm that uninstalling fprintd helps?
Comment 24 Wolfgang Ulbrich 2015-10-03 17:57:47 EDT
Looks like it is enough to disable fingerprint support with authconfig-gtk, maybe.
Comment 25 Wolfgang Ulbrich 2015-10-03 18:03:09 EDT
(In reply to Wolfgang Ulbrich from comment #23)
> Can confirm that uninstalling fprintd helps?
error......can you confirm please uninstalling fprintd helps?
Or using authcofig-gtk to disable it?
Comment 26 David Gibson 2015-10-05 20:45:56 EDT
Sorry, I never had fprintd installed, so I'm pretty sure that's not the problem in my case.

voom:~$ rpm -qa | grep -i fprint
voom:~$
Comment 27 Wolfgang Ulbrich 2015-10-06 04:33:26 EDT
[root@mother rave]# rpm -qa | grep -i fprint
libfprint-0.6.0-1.fc22.x86_64
fprintd-pam-0.6.0-1.fc22.x86_64
fprintd-0.6.0-1.fc22.x86_64


Weird, 'fprind' is in standard installation.
After i disabled the service with authconfig-gtk, i couldn't reproduce the issue anymore with my notebook running useless only for debugging this issue.
I suggest to run 'journlctl -b 0 -f --no-tail' in a second console.
There must be a hint.
Only you knows what happens on your notebook.
That the lockscreen change to 'sensitive' is a normal behaviour if typing a password isn't needed.
See https://github.com/mate-desktop/mate-screensaver/blob/master/src/gs-lock-plug.c#L1606
Comment 28 David Gibson 2015-10-06 19:59:03 EDT
> Weird, 'fprind' is in standard installation.

Yes, but I habitually prune my install fairly heavily.

> After i disabled the service with authconfig-gtk, i couldn't reproduce the issue anymore with my notebook running useless only for debugging this issue.
> I suggest to run 'journlctl -b 0 -f --no-tail' in a second console.

Ok, I'll run that and see what I can find.
Comment 29 David Gibson 2015-10-07 06:21:16 EDT
Finally reproduced for me with the journalctl running.  Not sure if you can make anything from this:

ct 07 21:09:08 voom org.mate.panel.applet.ClockAppletFactory[15435]: (clock-applet:15663): MateWeather-CRITICAL **: weather_info_abort: assertion 'info != NULL' failed
Oct 07 21:09:08 voom org.mate.panel.applet.ClockAppletFactory[15435]: (clock-applet:15663): MateWeather-CRITICAL **: _weather_info_fill: assertion '((info == NULL) && (location != NULL)) || ((info != NULL) && (location == NULL))' failed
Oct 07 21:10:15 voom kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training
Oct 07 21:10:15 voom kernel: [drm:intel_dp_complete_link_train [i915]] *ERROR* failed to start channel equalization
Oct 07 21:10:17 voom mate-session[15478]: WARNING: Detected that screensaver has left the bus
Oct 07 21:10:17 voom mate-screensaver-dialog[30404]: pam_unix(mate-screensaver:auth): conversation failed
Oct 07 21:10:17 voom mate-screensaver-dialog[30404]: pam_unix(mate-screensaver:auth): auth could not identify password for [dwg]
Oct 07 21:10:17 voom mate-screensaver-dialog[30404]: gkr-pam: no password is available for user
Oct 07 21:10:17 voom org.mate.panel.applet.ClockAppletFactory[15435]: (clock-applet:15663): MateWeather-CRITICAL **: weather_info_abort: assertion 'info != NULL' failed
Oct 07 21:10:17 voom org.mate.panel.applet.ClockAppletFactory[15435]: (clock-applet:15663): MateWeather-CRITICAL **: _weather_info_fill: assertion '((info == NULL) && (location != NULL)) || ((info != NULL) && (location == NULL))' failed
Oct 07 21:10:18 voom org.mate.panel.applet.ClockAppletFactory[15435]: (clock-applet:15663): MateWeather-CRITICAL **: weather_info_abort: assertion 'info != NULL' failed
Comment 30 Wolfgang Ulbrich 2016-01-10 09:47:01 EST
See https://github.com/mate-desktop/mate-screensaver/issues/82#issuecomment-170186186
Do you have Conky running?
Comment 31 David Gibson 2016-01-10 19:03:40 EST
No, I don't (in fact, never heard of it until now).

$ rpm -qa | grep conky
$ 

Sorry.
Comment 32 Fedora End Of Life 2016-07-19 16:19:43 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.