Bug 14599 - Authenticate dialog does not say when user/passwords are wrong.
Summary: Authenticate dialog does not say when user/passwords are wrong.
Status: RESOLVED NOTOURBUG
Alias: None
Product: PolicyKit
Classification: Unclassified
Component: libpolkit (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: David Zeuthen (not reading bugmail)
QA Contact: David Zeuthen (not reading bugmail)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-21 02:49 UTC by Murray Cumming
Modified: 2019-03-06 07:44 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Murray Cumming 2008-02-21 02:49:43 UTC
When calling ObtainAuthorization(), a dialog is shown allowing the user to enter their password (at least in Ubuntu Hardy Heron).

But when the wrong password is shown, the dialog is just re-shown, so all the user has as feedback is a flicker of the window rather than an explicit "The password was incorrect" message.


Also, when the user cancels, there is no message saying that the system has not allowed the user to access the feature, so applications need to show (and translate) an (awkward) message to explain why they can't use the feature. Having that message in PolicyKit would probably lead to more consistency.
Comment 1 David Zeuthen (not reading bugmail) 2008-02-21 07:42:05 UTC
(In reply to comment #0)
> But when the wrong password is shown, the dialog is just re-shown, so all the
> user has as feedback is a flicker of the window rather than an explicit "The
> password was incorrect" message.

And how would this work? Show a message for about five seconds? I don't think that's any good nor accessible. Isn't it evident for the user that he didn't authenticate directly when he gets the same dialog?

> Also, when the user cancels, there is no message saying that the system has not
> allowed the user to access the feature, so applications need to show (and
> translate) an (awkward) message to explain why they can't use the feature.
> Having that message in PolicyKit would probably lead to more consistency.

How do you propose we should explain this to the user? I think you really want application specific messages here; we can, at best, do only pretty generic stuff in PolicyKit.

Besides, I'm not a big fan of putting up modal dialogs explaining things to the user. The UI, in the first place, should use subtle hints (such as greying out items or using padlock icons) to convey that some feature is not available. And that's exactly what PolicyKit-gnome is for; see PolKitGnomeAction

 http://hal.freedesktop.org/docs/PolicyKit-gnome/PolKitGnomeAction.html

Scroll down a bit for the screenshot

 http://hal.freedesktop.org/docs/PolicyKit-gnome/polkit-gnome-example-screenshot.png
Comment 2 Murray Cumming 2008-02-21 09:22:11 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > But when the wrong password is shown, the dialog is just re-shown, so all the
> > user has as feedback is a flicker of the window rather than an explicit "The
> > password was incorrect" message.
> 
> And how would this work? Show a message for about five seconds? I don't think
> that's any good nor accessible.

It could be an extra label on the dialog. Well, that's what web pages tend to do. But there should be plenty of similar things to look at. I'm not the best person to decided how to do it - I just know that it needs something. usability@gnome.org might be able to provide some advice.

> Isn't it evident for the user that he didn't
> authenticate directly when he gets the same dialog?

No, I don't it's obvious.


> > Also, when the user cancels, there is no message saying that the system has not
> > allowed the user to access the feature, so applications need to show (and
> > translate) an (awkward) message to explain why they can't use the feature.
> > Having that message in PolicyKit would probably lead to more consistency.
> 
> How do you propose we should explain this to the user? I think you really want
> application specific messages here; we can, at best, do only pretty generic
> stuff in PolicyKit.

OK.

Comment 3 David Zeuthen (not reading bugmail) 2008-02-27 10:07:02 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > But when the wrong password is shown, the dialog is just re-shown, so all the
> > > user has as feedback is a flicker of the window rather than an explicit "The
> > > password was incorrect" message.
> > 
> > And how would this work? Show a message for about five seconds? I don't think
> > that's any good nor accessible.
> 
> It could be an extra label on the dialog. Well, that's what web pages tend to
> do. But there should be plenty of similar things to look at. I'm not the best
> person to decided how to do it - I just know that it needs something.
> usability@gnome.org might be able to provide some advice.
> 
> > Isn't it evident for the user that he didn't
> > authenticate directly when he gets the same dialog?
> 
> No, I don't it's obvious.
> 

Actually, I just remembered, we shake the dialog for half a second if there's an authentication error. So it's not true there is not feedback. But we might add an error message too in the future.
Comment 4 Murray Cumming 2008-03-05 04:46:32 UTC
> Actually, I just remembered, we shake the dialog for half a second if there's
> an authentication error. So it's not true there is not feedback. But we might
> add an error message too in the future.

Yes, I saw that shake but didn't realize that it was intended.
Comment 5 James Westby 2008-09-10 03:09:12 UTC
Hi,

In response to

http://blogs.sun.com/richb/entry/a_gnome_lock_screen_accessibility

I tried to get a design proposal for this from the orca folks

http://mail.gnome.org/archives/orca-list/2008-May/msg00868.html

there weren't many suggestions, I think this message was the most
helpful

http://mail.gnome.org/archives/orca-list/2008-May/msg00877.html

Thanks,

James
Comment 6 David Zeuthen (not reading bugmail) 2009-10-21 10:32:22 UTC
This should be filed at b.g.o if it is still relevant. Thanks.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.