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 685307 - Blue login button oddities
Blue login button oddities
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: login-screen
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: Ray Strode [halfline]
gnome-shell-maint
Depends on: 687110 687112 687113
Blocks:
 
 
Reported: 2012-10-02 15:31 UTC by Allan Day
Modified: 2012-11-20 20:26 UTC
See Also:
GNOME target: ---
GNOME version: 3.7/3.8



Description Allan Day 2012-10-02 15:31:55 UTC
If I press the button with the pointer and release, the button appears pressed but then the label changes to a dark color for a short while. If I press the return key, the button doesn't appear pressed and the label changes to the dark color.

Pressing the button with either the pointer or the return key should simply result in the button having a pressed appearance. Afterwards, it should immediately return to normal.
Comment 1 Stéphane Démurget 2012-10-26 08:26:47 UTC
The button and the entry are insensitive until the auth is done to avoid multiple clicks and hammering the auth system.

We might try to restore the sensitivity as soon as auth succeeds, before the curtain animation starts, but maybe the entry/button can still be used for an instant and that would require to use a "looking glass" to stop input on them?

But more generally, isn't it because the button theming does not really make it look like it's disabled? It could be darken more globally (darker blue). I'd like to test on other mobile devices, but I think even on touch screens it makes sense to disable the input since the auth might take time.
Comment 2 Allan Day 2012-10-29 10:37:29 UTC
Ah, I hadn't realised that the button is going insensitive!

So, there are a few things we can do here:

 1. Improve the insensitive button styling so it actually looks insensitive
 2. Make the password entry box insensitive while authorisation takes place
 3. Put a progress spinner next to the login button if authorisation takes longer than about half a second

Mockups:

 * https://dl.dropbox.com/u/5031519/gnome-shell/login/1-incomplete.png
 * https://dl.dropbox.com/u/5031519/gnome-shell/login/2-sensitive.png
 * https://dl.dropbox.com/u/5031519/gnome-shell/login/3-progress.png
Comment 3 Allan Day 2012-10-29 12:56:16 UTC
Also included in the mockups:

 4. Make the Login button insensitive when there isn't any text in the password field

We can tackle these as separate bugs, so I've filed bug 687110, bug 687112 and bug 687113. I'm leaving this here as a tracker bug.
Comment 4 Stéphane Démurget 2012-10-29 22:56:53 UTC
Unfortunately, I think having split this in multiple bugs will make it more difficult to handle because the patches work on similar areas.

If it is easier for maintainers I can attach all the patches on this tracker bug as a patch series that is easier to apply, otherwise I'll need to rebase between each patch application.
Comment 5 Florian Müllner 2012-10-29 23:23:43 UTC
(In reply to comment #4)
> I can attach all the patches on this bug, otherwise I'll need to rebase
> between each patch application.

It's OK to have dependencies between bugs, so both individual bugs or a patch series are fine - basically pick whichever you prefer.
Comment 6 Allan Day 2012-11-20 20:26:18 UTC
All done. Stéphane is my hero.