Closed Bug 395096 Opened 17 years ago Closed 1 year ago

No Quick Way to Focus Remember Password Prompt

Categories

(Toolkit :: UI Widgets, defect)

Product:
Toolkit
Component:
UI Widgets
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: tkeenan, Unassigned)

Details

(Keywords: access) 

There's no way to quickly focus the alert asking whether to remember a password.
To reproduce:
1. Log into a new site or otherwise cause the Remember Password alert to be displayed.
2. Notice that it doesn't grab focus, which is intentional.

The problem is there's no easy way to focus this with the keyboard.  In order to do so, you need to press ctrl+l, then tab twice.  This is unacceptable for release.  
If we're going to keep these non-intrusive alerts, we're going to need something like a keyboard command to focus the alert pane.
This would be tough to fit into standard Windows/Linux conventions.  All I can think of would be f6, which is used to switch between parts of a window.  
The bottom line is that from both a screen reading and magnification perspective, something like this causes a considerable headache.

Thoughts?  Am I overreacting?
Whiteboard: [passwordManager-ui]
Whatever solution we find for the notification box, we should use for the new notifications hanging off of the favicon in the future.   Could we change the text read by the screen reader to say something like "If you would like firefox to remember your password, hit F6" to improve discoverability of the keyboard command?
The interesting part is that the alert itself is accessible--once I give focus to it I can tab correctly through the buttons.  That's not the case with the Add Bookmark widget, which reports itself as a menu.  Could we use the same technique used in this alert for the Add Bookmark popup, except we'll actually give focus to the bookmark popup upon triggering it?

Spoken by someone who doesn't know as much as he should about the code.

If you have a button with an accesskey that button should be read by the screen reader.

For example:
Firefox has blocked a popup  [_O_ptions]
would be read as somthing like
Firefox has blocked a popup, button Options Alt+T

- If the screen reader isn't reading the accesskey it's a bug in the screen reader
- Does this remember password prompt currently include accesskeys?

If it works that way you don't need to be able to focus it at all.
The password manager notifications do have accesskeys on the buttons.
They do. Tim, is Window-Eyes speaking the accesskeys on the buttons? If not, I believe it's a bug in Window-Eyes.

I'd also like to know whether JAWS, Orca and NVDA do the right thing.
Jaws speaks the alert ("Do you want Firefox to remember this password?" three times, then "Remember, alt+r, Never for This Site, alt+e, close this message."  Window-eyes speaks the alert once then the buttons, including the two with shortcut keys.  (Close this message doesn't have a shortcut key and it probably needs one, since escape doesn't close it, even if the alert pane has focus.)
My NVDA install on my notebook is currently broken and not easily fixable, so I have no info on that at the moment.
 
I didn't think of the fact that the shortcut keys would be valid while the main browser content area is focused, but it does appear to work.    That's great for screen-reader users.  Now we need some low-vision users to chime in.  I'm in the process of getting some Zoomtext users involved. It's just taking longer than I'd like.



Although pressing the shortcut key works correctly, focus is lost.  I'm not sure where it ends up, but it definitely leaves the browser content area.  Pressing tab takes you to the location bar, and shift+tab takes you to the browser area.
I'll try to figure out what's happening using Accevent.
It would be ideal if pressing a shortcut key didn't move the focus.  Is that possible or would that involve rewriting a handler that would affect other things?

It looks like the shortcut key is giving focus to the button, which then disappears, and focus is just being given to the window in general.
Someone correct me if I'm wrong.

We should just fix the buttons inside alerts so they return focus to where it was.

As far as ZoomText, I already had them alter ZoomText to ensure that alerts are in the visible area. ZoomText will scroll to the alert if necessary.
Target Milestone: Firefox 3 M9 → ---
It used to be R for remember, now someone mentioned in bug 427096 that I posted a few hours ago that we have to use two keys? Who keeps changing GUI insisting that more steps to achieve the same functionality is acceptable?
Just an opinion... I really like the way FF2 handles this by defaulting focus to "Not Now"
Product: Firefox → Toolkit
So, I'm not clear on the state of this bug.

The "remember password?" notification bar has access keys, they work (for me), and screen readers can apparently deal with the bar. I guess the question is if screen readers are incorrectly announcing the button multiple times, and if focus is shifting somewhere it shouldn't?

In any case, nothing here should be unique to the "remember password" bar, so I'm moving this to the XUL Widgets components where notification bar bugs live.
Component: Password Manager → XUL Widgets
QA Contact: password.manager → xul.widgets
Whiteboard: [passwordManager-ui]
The state is clear: pressing R does not remember the password.

The new keyboard combination is anti-intuitive, whatever it is. I have no arguments against and agree with Nick (comment #11) that 'Not Now' should be given focus.

Pressing (just the) 'R' key should activate the remember button. With Firefox 3 we now have to manually move the mouse over. I know there is some sort of keyboard combination to activate remember but like I said it's counter-intuitive.

...of course every time I post a perfectly clear bug report someone else has beaten me to it with a less then clear report. I recommend checking my "duplicate" bug reports for better details. It's frustrating because many of my reports end up as duplicates.

It would help to underline the letter to which the key associated with it's activation is associated with. R/remember, N/not now, etc.
(In reply to comment #13)
> The state is clear: pressing R does not remember the password.

No. Otherwise typing an "R" on the page you've logged into would unexpectedly save the password.

In any case, that's not what this bug is about. This bug is about the accessibility of notification bars with respect to screen readers and the like.
1.) The person surfing presses enter and waits for the browser to react, there is no reason for them to continue typing at that point.

2.) Then remove the duplicate status from bug 427096.
>Otherwise typing an "R" on the page you've logged into would unexpectedly
>save the password.

Yeah, these things can't steal the focus away (that's rather the whole point of the design).  Any key combinations are going to need an accelerator key.
Marco is this bug still valid?
Flags: needinfo?(marco.zehe)
David, yes. I just removed a saved password, went to one of my domains, entered the authentication credentials, hit enter and when it asked me to save my password no focus was given and obviously pressing R. Not sure WTF F6 key is coming in to play, that would be completely anti-intuitive, non-consistent and thus bad design.
Thanks David but I've been directed to twenty places thus far of other places that things related to bugs should be discussed. My point is pretty simple: restore previous functionality. I'm not debating nor will I debate with someone trying to change something. When I say 'change' I do not mean 'fix' and when I say 'fix' I do not mean 'change'. "r" was the original correct key to which should be given focus. Changing it to F6 would 'change' the bug from not focus to wrong key and remain inconsistent in design, making the 'r' key give focus where is belongs would 'fix' the bug. I am not going to blow dozen more hours messing around with incorrectly unorganized Mozilla sites where half of the Mozilla staff have been busy destroying our browser while the other half actually make a legitimate effort to fix it (which ends up being about 5% of the bugs that I've encountered). I'm still waiting for the Go button to return in example. Someone may want to pass that along because bug discussions belong on bug reports.
Well, except for the problems we still have with Doorhangers and keyboard accessibility/control focusability, as described in bug 616136 and dependencies. Since the UI has changed from when I filed this bug originally, I think we have to solve those problems once and for all, and then can close this one here as WFM.
Flags: needinfo?(marco.zehe)
I came to file a related issue but am glad this is being discussed already.

It used to be that pressing ALT+R would remember the password and close the dialog. This made sense for me, since "R" was an intuitive Alt key for this action.

I do disagree that pressing "R" alone is a bad idea. But ALT+R should be fine.

Again, ALT+R worked perfectly a little while ago - possibly around FF12 or something?

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --

Looks like F6 works now

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.