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 642999 - Lock buttons should not be insensitive if an authorization can be obtained
Lock buttons should not be insensitive if an authorization can be obtained
Status: RESOLVED NOTGNOME
Product: gnome-control-center
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
: 644095 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-02-22 20:49 UTC by David Zeuthen (not reading bugmail)
Modified: 2011-03-07 16:06 UTC
See Also:
GNOME target: 3.0
GNOME version: ---


Attachments
Short video illustrating the problem (377.98 KB, video/webm)
2011-02-22 20:49 UTC, David Zeuthen (not reading bugmail)
Details

Description David Zeuthen (not reading bugmail) 2011-02-22 20:49:06 UTC
Created attachment 181636 [details]
Short video illustrating the problem

After click the lock, if I either dismiss the password dialog or type in the wrong password, the lock button turns insensitive. It really shouldn't do this since there is no apparent way to fix this. 

The proposed GTK+ lock button widget in bug 626457 certainly doesn't work this way.

Note that the problem is a lot worse in gnome 3 with the recently landed polkit authentication agent (see bug 642886) because unlike the GNOME 2 auth agent, this auth agent will not re-ask for auth if you fail.

I have attached a screencast illustrating the problem.
Comment 1 David Zeuthen (not reading bugmail) 2011-02-22 20:52:47 UTC
(In reply to comment #0)
> Created an attachment (id=181636) [details]
> Short video illustrating the problem
> 
> After click the lock, if I either dismiss the password dialog or type in the
> wrong password, the lock button turns insensitive. It really shouldn't do this
> since there is no apparent way to fix this. 

Sorry, if this is unclear. With 'fix this', I meant that there's no apparent way of clicking the lock again (the not-so-apparent way is to click "All Settings" and go back in the Accounts panel).
Comment 2 David Zeuthen (not reading bugmail) 2011-02-22 20:54:33 UTC
(this issue came up in the polkit bugzilla whilst discussing adding a way to figure out if the authentication dialog was dismissed. See https://bugs.freedesktop.org/show_bug.cgi?id=30653 for more details)
Comment 3 David Zeuthen (not reading bugmail) 2011-02-22 20:59:16 UTC
Updating bug summary to be more precise.
Comment 4 David Zeuthen (not reading bugmail) 2011-02-23 14:43:15 UTC
Actually this is caused by this bug

 https://bugs.freedesktop.org/show_bug.cgi?id=32334

and I think the proposed patch there will make it work. Stay tuned while I test it.
Comment 5 David Zeuthen (not reading bugmail) 2011-02-23 15:06:29 UTC
Yup, with the PolicyKit fix, this is no longer an issue. Closing as NOTGNOME.
Comment 6 Bastien Nocera 2011-03-07 16:06:44 UTC
*** Bug 644095 has been marked as a duplicate of this bug. ***