After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660919 - login dialog becomes nonreactive after clicking Authentication Failure notification
login dialog becomes nonreactive after clicking Authentication Failure notifi...
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: login-screen
3.1.x
Other Linux
: Normal normal
: ---
Assigned To: Ray Strode [halfline]
gnome-shell-maint
: 661038 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-10-04 19:39 UTC by Ray Strode [halfline]
Modified: 2011-10-17 17:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
messageTray: only set stage input mode when necessary (2.24 KB, patch)
2011-10-17 04:33 UTC, Ray Strode [halfline] 		committed Details | Review

Description Ray Strode [halfline] 2011-10-04 19:39:51 UTC 
jrb noticed if he clicks the "Authentication Failure" notification after entering an invalid password, the user list becomes non-reactive until he switches focus to the top panel (by using ctrl-alt-tab or clicking a menu)
Comment 1 Jasper St. Pierre (not reading bugmail) 2011-10-06 00:39:13 UTC 
*** Bug 661038 has been marked as a duplicate of this bug. ***
Comment 2 Ray Strode [halfline] 2011-10-17 04:33:59 UTC 
Created attachment 199169 [details] [review]
messageTray: only set stage input mode when necessary

The message tray focus grabbing code sets the stage input
mode to Shell.StageInputMode.FOCUSED when the overview is
not visible. This ensures the stage window's input
region gets reshaped to include the notification chrome,
and so that input events get delivered appropriately to
the notification that grabbed focus.

The message tray code never tries to restore the stage input
mode later. Instead, the code relies on the stage input
mode (and input region) getting reset to
shell.StageInputMode.NORMAL automatically when focus moves
back from the shell chrome to a window in the user's session.

It's not really correct to set the stage input mode based
on the overview's visibility, though. At the login screen,
even though no overview is visible, the stage input mode is
Shell.StageInputMode.FULLSCREEN which is sufficient
for the notification's needs,  Furthermore,
Shell.StageInputMode.FOCUSED is insufficient for the login
dialog's needs since the login dialog isn't considered
part of the shell's chrome and won't get included in the
stage input region.

This commit changes the message tray code to only set the
stage input mode if the current stage input mode isn't good enough,
rather than assuming the input mode isn't good enough just because
the overview is hidden.
Comment 3 Jasper St. Pierre (not reading bugmail) 2011-10-17 14:34:16 UTC 
The easier and probably better fix would be to just make the login dialog part of the Chrome.
Comment 4 Ray Strode [halfline] 2011-10-17 15:02:50 UTC 
It was originally part of the chrome and Dan didn't want it to be. See bug 657082 comment 43.

I really don't character either way, but if we do make it part of the chrome we should still apply attachment 199169 [details] [review] because it's more conceptually right than what's their now and matches what other parts of the code do (see ctrlAltTab.js for instance)
Comment 5 Ray Strode [halfline] 2011-10-17 15:03:07 UTC 
s/character/care/
Comment 6 Jasper St. Pierre (not reading bugmail) 2011-10-17 15:09:19 UTC 
Review of attachment 199169 [details] [review]:

LGTM.
Comment 7 Ray Strode [halfline] 2011-10-17 17:24:25 UTC 
Attachment 199169 [details] pushed as 12e3921 - messageTray: only set stage input mode when necessary