Closed Bug 617872 Opened 9 years ago Closed 9 years ago
Focus manager allows F6 to focus elements inside non-focusable iframes/browsers
When tab-modal prompts first landed (bug 59314), they didn't do any special focus handling, so you could end up in a state where the prompt was showing but focus was in the page, which is at the very least confusing. Bug 613763 mostly fixed the problem, so you can no longer shift focus into the web page by pressing tab. However, you can still shift focus there by using F6. I think this is actually something the focus manager needs to deal with (ie, make it handle F6 as Tab is currently handled)... Seems like nsFocusManager::MoveFocus() + MOVEFOCUS_FORWARDDOC shouldn't advance focus into a subtree that's non-focusable. Tab (MOVEFOCUS_FORWARD) seems to take a slightly different codepath that prevents this. Ie, when a document is inside a <browser> with | -moz-user-focus: none|, neither tab nor F6 should focus that document. From bug 613763 comment 13: I wasn't able to get the F6 listener working. It can't just be a <handler> in tabprompts.xml, because it needs to run when key input is targeting other parts of the window (like the URL bar). Even then, as a global listener, it would need to know where focus is going to shift _to_, not what the key event's target is. At least, AIUI, the relevant code is nsEventStateManager::PostHandleEvent(), wherein the keypress==F6 case is calling focus manager's moveFocus with MOVEFOCUS_FORWARDDOC / MOVEFOCUS_BACKWARDDOC. I suppose the alternative would be for the tabprompt to add a capturing focus listener on domWin.top, and cancel/blur it? But shouldn't the focus manager be skipping over the page when it's inside a non-focusable browser / parent chain? Seems like this should be suppressed just as tab is.
Summary: Focus manager allows F6 to focus elements inside non-focusable elements → Focus manager allows F6 to focus elements inside non-focusable iframes/browsers
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
As mentioned in bug 613763 (and sorry for double-posting), maybe this isn't an error but a valid way for users to see possible-relevant information to respond to the modal prompt? It also allows for "quick-searching" and I found it useful in some scenarios, so if possible I think I rather keep this behavior --I haven't needed to move across frames, but it could certainly be useful (in a "read-only mode").
*sigh* Neil: The patch fixes the problem for me on Windows 7. Though I did notice that F6 won't move focus back to the tab-modal prompt. I guess that's expected, though, since the prompt is part of the chrome document. Is this ready for review, or were there other bits to clean up?
(In reply to comment #4) > Neil: The patch fixes the problem for me on Windows 7. Though I did notice that > F6 won't move focus back to the tab-modal prompt. I guess that's expected, > though, since the prompt is part of the chrome document. F6 will focus the first focusable element in the tab order in the chrome document.
Attachment #496599 - Flags: review?(Olli.Pettay)
Attachment #496599 - Flags: review?(Olli.Pettay) → review+
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b9
You need to log in before you can comment on or make changes to this bug.