Closed Bug 433028 Opened 16 years ago Closed 12 years ago
closing the password save bar does not set focus back to web page
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20080404 Firefox/184.108.40.206 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050406 Minefield/3.0pre If you go to the a page with a password and Firefox 3 asks whether you want to have it save the password, focus is not set back to the web page. Reproducible: Always Steps to Reproduce: 1. Start accevent and for name, value, HWND and classname. 2. Type an arbitrary user name and password to the above web page. Notice the HWND that the focus events get sent to 3. Hit enter to submit the password. A bar comes up asking "remember", "never for this site" and "not now" 4. Choose one of these options with the keyboard shortcut Actual Results: There are no focus events back to the document window, just one to the application and one to the button that was selected Expected Results: The last focus would be to the window that contains the web page This causes GW Micro's screen reader to leave browse mode off even though the users should still be able interact with the page in browse mode. It is very difficult to recover, even when there are multiple tabs open and you control-tab through them. The tab that was broken the password request does not recover focus after cycling through the tabs. When it is broken and you look at a Window-Eyes dumpOSM (Ctrl+Shift+Alt+D), the OS focus is an immediate child of the "MozillaUIWindowClass" classed window instead of a child of the window with the correct class "MozillaContentWindowClass"
I have no problem tabbing or shifttabbing back to the page content after the button for the password reminder gained focus. I can continue working normally after that using JAWS. Bill, what happens after you select the "Never for this site" button, if you tab or shift tab once?
I'm also able to duplicate this as Bill wrote. When you press one of the shortcuts for the password bar, the password bar closes. It's at that point where things get screwed up. If you get focus in the password bar, and tab around, that's fine -- there's no problem there. It's after you select a choice, and then go (supposedly) back to the page. This is where focus is getting lost.
This is still a problem in latest trunk builds. After activating *any* of the buttons in the notification bar, focus stays on the button that has just disappeared. At least for screen reader users.
This still happens with the new Doorhanger notifications.
This is still a problem with doorhangers in the current Firefox 10.0a1 nightly builds. If one presses Space on the "Close this message" of *any* doorhanger prompt, focus does not get set to a defined spot (like back to the document or previously focused item within the document). Keyboard focus is lost until one presses tab or shift tab.
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
(In reply to Marco Zehe (:MarcoZ) from comment #5) > This is still a problem with doorhangers in the current Firefox 10.0a1 > nightly builds. If one presses Space on the "Close this message" of *any* > doorhanger prompt, focus does not get set to a defined spot (like back to > the document or previously focused item within the document). Keyboard focus > is lost until one presses tab or shift tab. I can see the focus is fired on document accessible of Firefox UI window and this is announced by NVDA.
Marco, can you confirm?
I can confirm this, yes. The one thing that still bothers me is the fact that, when pressing tab after focus lands on the document, it is not set on the first focusable item of the document, but on the awesome bar instead.
Dao, can you take a look please (see comment #8)
Target Milestone: --- → Firefox 15
Version: Trunk → 16 Branch
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.