Closed Bug 277808 Opened 21 years ago Closed 21 years ago

Need keyboard binding to release focus from widgets that block keyboard navigation and shortcuts

Categories

(Firefox :: Keyboard Navigation, defect)

x86
Linux
defect
Not set
minor

Tracking

()

RESOLVED DUPLICATE of bug 146045

People

(Reporter: cworth, Assigned: aaronlev)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 There is a class of widgets, (including text form fields, form submission buttons, the location bar, etc.), that block keyboard navigation and other shortcuts when they have focus. That much is not a bug, as it's necessary to be able to type a literal "/" in a form field rather than triggering FastFind. However, for keyboard-based navigation, it's necessary to have a kayboard-based means of releasing the focus from the widget so that things such as Ctrl-N or "/" for FastFind will work again. I propose that the ESC key should act as a general "focus release" binding wherever applicable. There are two workaround that I use currently, but both are inadequate: 1) Clicking outside the widget. (This has the precisely desired effect on focus, but is unacceptable UI in terms of keyboard-navigation as it requires using the mouse) 2) The TAB key. This is keyboard-based, but is inadequate as it merely moves focus to the next widget, (rather than releasing to the parent or whatever). The next widget may also act the same as the current widget, requiring an unbounded number of TAB presses before finding a "good" widget that allows "/" for search or "Ctrl-N" for new window. It seems that the implementation of ESC to release focus could be modeled after the behavior from "click on main content pane". Reproducible: Always Steps to Reproduce: Type the following: 1. Ctrl-L 2. google.com <Enter> 3. ESC 4. /Images 5. Ctrl-N Actual Results: After step 2, the text input form field gets focus (which is fine). At step 3 there is no change. At step 4, the text "/Images" appears in the text field. Step 5 actually does open a new window, but Ctrl-N inside the multi-line field I'm using to type this paragraph does not. Expected Results: At step 3, the text field should release focus, so that typing "/Images" will highlight the Images link for keyboard navigation. The use of ESC in some fields already has its own semantic meaning. For example: Location bar: ESC cancels text entry, restoring current URL and highlighting it. Text input fields: ESC destroys current text input. In either case, the current behavior can be manintained, (perhaps requiring an additional keypress of ESC to release focus). But this should only be required if the first press of ESC performs some actual action with a visible state change. For example, pressing ESC in an already empty text field should release focus immediately. (And I should mention that I would prefer ESC-releases-focus for text input fields rather than ESC-destroys-user-input-data, but that would be a separate bug).
Dup of bug 146045?
yeah, sounds like it. *** This bug has been marked as a duplicate of 146045 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.