Closed
Bug 229100
Opened 22 years ago
Closed 21 years ago
shift-tab is broken inside search-bar
Categories
(Firefox :: Toolbars and Customization, defect, P2)
Firefox
Toolbars and Customization
Tracking
()
VERIFIED
FIXED
Firefox1.0beta
People
(Reporter: kbrosnan, Assigned: mconnor)
References
Details
(Keywords: fixed-aviary1.0, regression)
Attachments
(1 file)
805 bytes,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+
If focus is in the quick search box, shift tab does nothing.
Reproducible: Always
Steps to Reproduce:
1. click in the quick search box
2. press shift tab
Actual Results:
nothing happens focus remanins in search box
Expected Results:
Focus should have switched to the address bar.
Comment 1•22 years ago
|
||
Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a)
Gecko/20040110 Firebird/0.8.0+ (mozJF)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•22 years ago
|
||
Confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a)
Gecko/20040106 Firebird/0.7+
Comment 3•22 years ago
|
||
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a)
Gecko/20040127 Firebird/0.8.0+ (scragz).
-> Changed summary to better fit the problem.
OS: Windows XP → All
Summary: shift tab broken in quick search → shift-tab is broken inside search-bar
Assignee | ||
Comment 4•22 years ago
|
||
*** Bug 234766 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 5•22 years ago
|
||
From Jesse Ruderman in the dupe:
"This worked in Dec 2 builds and stopped working in Dec 3 builds. It might have
been caused by Ben's fix for bug 171606."
Keywords: regression
Updated•22 years ago
|
Assignee: hyatt → bugs
Comment 6•22 years ago
|
||
Cannot shift-tab backwards completely through window.
This makes movement from first link to last link which,
should only take three shift-tabs impossible to do.
It makes navigation without a mouse more difficult as
you can only move in one direction and, if you miss it,
you have to tab all of the way forward again.
I think that this should be an accessibility issue also -
if that category were available for Firefox.
Comment 7•22 years ago
|
||
This is also annoying because you can TAB from the URL bar to the search bar, so
if you fat-finger the tab key while typing in a URL, you can't undo the damage
without the mouse.
Comment 8•22 years ago
|
||
*** Bug 238179 has been marked as a duplicate of this bug. ***
Comment 9•22 years ago
|
||
*** Bug 239145 has been marked as a duplicate of this bug. ***
Comment 10•21 years ago
|
||
*** Bug 240200 has been marked as a duplicate of this bug. ***
Comment 11•21 years ago
|
||
Confirmed on Solaris
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.6) Gecko/20040403 Firefox/0.8
Reporter | ||
Comment 12•21 years ago
|
||
This breaks keyboard navigation in the browser, so I am nominating for blocking 1.0.
Flags: blocking1.0?
Comment 13•21 years ago
|
||
You can come back with the keyboard, but the user don't always know every
shortcuts like CTRL-L
Flags: blocking1.0+
Flags: blocking0.9+
Comment 14•21 years ago
|
||
Only peers should be setting these to +
Flags: blocking1.0+
Flags: blocking0.9?
Flags: blocking0.9+
Assignee | ||
Comment 15•21 years ago
|
||
yeah, this is annoying, time to get some traction on it, but its not critical
for 0.9
Assignee: bugs → mconnor
Flags: blocking1.0?
Flags: blocking1.0+
Flags: blocking0.9?
Flags: blocking0.9-
Priority: -- → P2
Target Milestone: --- → Firefox1.0beta
Comment 16•21 years ago
|
||
*** Bug 242853 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Hardware: PC → All
Comment 17•21 years ago
|
||
Broken UI components that should take a few minutes to fix aren't critical?
Comment 18•21 years ago
|
||
I switched from Firebird $something_reliable to 0.9 and this annoyed me SO MUCH
I felt compelled to deal with it after about 3hours! :-)
The problem is that `search-proxy-button' (the Google/OtherSearchEngine dropdown
selector) is getting the focus and then immediately giving it to its parent
('seach-container/search-bar'). In the process of figuring out XUL, I tried
various fixes including the settting the tabindex="2" and having a
onfocus/onblur handler deal with it but these all introduced small side-effects.
The best fix seems quite simply to add:
#search-proxy-button {
-moz-user-focus: none;
}
somewhere appropriate (eg. `browser.css').
-Paul Sladen
Assignee: mconnor → bugs
Assignee | ||
Comment 19•21 years ago
|
||
any particular reason you reassigned this?
-> taking back.
Assignee: bugs → mconnor
Assignee | ||
Comment 20•21 years ago
|
||
Assignee | ||
Comment 21•21 years ago
|
||
fixed, branch and trunk
thanks for tracking this down Paul!
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Whiteboard: fixed-aviary1.0
Comment 22•21 years ago
|
||
*** Bug 249983 has been marked as a duplicate of this bug. ***
Comment 23•21 years ago
|
||
*** Bug 250919 has been marked as a duplicate of this bug. ***
Comment 24•21 years ago
|
||
*** Bug 252310 has been marked as a duplicate of this bug. ***
Comment 25•21 years ago
|
||
*** Bug 252557 has been marked as a duplicate of this bug. ***
Comment 26•21 years ago
|
||
*** Bug 253799 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Keywords: fixed-aviary1.0
Whiteboard: fixed-aviary1.0
Comment 27•21 years ago
|
||
*** Bug 257418 has been marked as a duplicate of this bug. ***
Comment 28•21 years ago
|
||
*** Bug 257712 has been marked as a duplicate of this bug. ***
Comment 29•21 years ago
|
||
*** Bug 257842 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Status: RESOLVED → VERIFIED
Updated•19 years ago
|
QA Contact: bugzilla → toolbars
You need to log in
before you can comment on or make changes to this bug.
Description
•