shift+tab moves to extra spot in pulldown menus in html forms

RESOLVED FIXED

Status

()

Core
Keyboard: Navigation
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: sairuh (rarely reading bugmail), Assigned: Aaron Leventhal)

Tracking

({regression})

Trunk
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

14 years ago
found using 2004081312-trunk Firefox bits (I bet it's also in Seamonkey, hence
filing here).

this is *not* a problem on the (Firefox aviary1.0) branch.

1. go to a page containing pulldown menus (<select>), such as the bugzilla query
form, http://bugzilla.mozilla.org/query.cgi --scroll down to Advanced Query
Using Boolean Charts.

2. place caret in the rightmost textfield (near the Or button).

3. hit Shift+Tab to move focus to the middle pulldown menu.

expected: focus ring should be around the first item in the <select>.

actual results: no focus ring, instead a caret-like object is over the pulldown
menu's down arrow widget. you need to hit shift+tab again to actually move focus
onto the first item of the <select>.

oddly, this isn't a problem moving focus in the forward direction (hitting tab).
(Reporter)

Comment 1

14 years ago
wonder if the fix for bug 175893 caused this.

2004071321-trunk (seamonkey) doesn't exhibit this, but a seamonkey build from
2004073014-trunk does.

will narrow down somemore.
(Reporter)

Comment 2

14 years ago
hm, bug 175893 prolly didn't cause this, because of the regression window:

2004072907-trunk: works fine
2004073008-trunk: broken

Comment 3

13 years ago
bug 252984, perhaps?
(Reporter)

Comment 4

13 years ago
Andrew, thanks for tracking that down! the timing of the checkin is right. Aaron?
(Assignee)

Comment 5

13 years ago
Created attachment 157353 [details] [diff] [review]
Special case: Anonymous button child of <select> is not focusable

I couldn't think of a more general rule. There are other times where anonymous
form controls should be focusable, e.g. <input type="file">
(Assignee)

Comment 6

13 years ago
Comment on attachment 157353 [details] [diff] [review]
Special case: Anonymous button child of <select> is not focusable

Maybe Neil can think of a more elegant way, or maybe we need to use a special
case for the drop down button.

The reason it regressed was that I fixed it so that a focusable ancestor is
allowed to have focusable children. This is necessary for things like a DHTML
tree view.
Attachment #157353 - Flags: superreview?(neil.parkwaycc.co.uk)

Comment 7

13 years ago
Well, according to forms.css:129 it is special-cased:
select > input[type="button"] {
  width: 12px;
  height: 12px;
  white-space: nowrap;
  -moz-user-focus: none;
So why isn't this style taking effect? The rest of the block works, for instance
I was able to change the background colour of all the dropmarkers to red.
(Assignee)

Comment 8

13 years ago
Ah, that's because we ignore -moz-user-focus in IsFocusable() for HTML. We're
only using that as a hint for XUL right now. I can utilize that hint for HTML too.
(Assignee)

Comment 9

13 years ago
Okay, if we use -moz-user-focus in HTML, how do we prevent children of an <a>
from becoming focusable?
(Assignee)

Comment 10

13 years ago
(In reply to comment #9)
> Okay, if we use -moz-user-focus in HTML, how do we prevent children of an <a>
> from becoming focusable?
Also a problem for <button>

I can't figure out how to change nsRuleNode::ComputeUserInterfaceData so that
-moz-user-focus: normal doesn't get inherited by child elements. We also have to
be careful because -moz-any-link may also be inherited, and that contains the
rule -moz-user-focus: normal

Comment 11

13 years ago
OK, so instead can the creator of the button give it a tabIndex of -1?
*** Bug 258015 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

13 years ago
Attachment #157353 - Flags: superreview?(neil.parkwaycc.co.uk)
(Assignee)

Comment 13

13 years ago
Created attachment 158105 [details] [diff] [review]
Using Neil's concept: set tabindex="-1" for anon drop down button

I also tested to make sure that clicking on the button sets focus to the
textfield like it always has.

I'd prefer not to fix this by making -moz-user-focus work again, because I want
people to use the IE-compatible tabindex method of making arbitrary HTML
focusable/tabbable. On the other hand -moz-user-focus is a Mozilla-only hack
and has been removed from CSS3. This means we should probably take all of the
-moz-user-focus lines out of html.css, forms.css, quirks.css etc.
(Assignee)

Updated

13 years ago
Attachment #157353 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #158105 - Flags: superreview?(neil.parkwaycc.co.uk)

Comment 14

13 years ago
Comment on attachment 158105 [details] [diff] [review]
Using Neil's concept: set tabindex="-1" for anon drop down button

Looks good to me, given what I know about layout...
Attachment #158105 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
(Assignee)

Updated

13 years ago
Attachment #158105 - Flags: review?(bryner)
Comment on attachment 158105 [details] [diff] [review]
Using Neil's concept: set tabindex="-1" for anon drop down button

I think the attribute should be set in CreateAnonymousContent, but otherwise
looks ok.
Attachment #158105 - Flags: superreview-
Attachment #158105 - Flags: superreview+
Attachment #158105 - Flags: review?(bryner)
Attachment #158105 - Flags: review+
(Assignee)

Comment 16

13 years ago
Created attachment 158230 [details] [diff] [review]
Better place to add attribute
Attachment #158105 - Attachment is obsolete: true
Attachment #158230 - Flags: review+
(Assignee)

Comment 17

13 years ago
Checking in nsComboboxControlFrame.cpp;
/cvsroot/mozilla/layout/html/forms/src/nsComboboxControlFrame.cpp,v  <-- 
nsComboboxControlFrame.cpp
new revision: 1.294; previous revision: 1.293
done
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(In reply to comment #10)
> I can't figure out how to change nsRuleNode::ComputeUserInterfaceData so that
> -moz-user-focus: normal doesn't get inherited by child elements. We also have to
> be careful because -moz-any-link may also be inherited, and that contains the
> rule -moz-user-focus: normal

Well, I never understood what -moz-user-focus was supposed to do, so I can't
really comment on whether it should be inherited or not.  Perhaps it came from
http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-focus .  To change it
from an inherited to a reset property, you'd need to:
 * move mUserFocus from nsStyleUserInterface to nsStyleUIReset (nsStyleStruct.h
and .cpp)
 * change the macro used in the appropriate line in nsCSSPropList.h
(CSS_PROP_USERINTERFACE to CSS_PROP_UIRESET, or whatever it is)
 * move the computation code in nsRuleNode
 * change all the callers that use it to get the different struct
(and perhaps something else I'm missing, but that's probably it)
You need to log in before you can comment on or make changes to this bug.