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)
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).
Comment 1•21 years ago
|
||
Dup of bug 146045?
Comment 2•21 years ago
|
||
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.
Description
•