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

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[sairuh (rarely reading bugmail)]

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).

Comment 1

[sairuh (rarely reading bugmail)]

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.

Comment 2

[sairuh (rarely reading bugmail)]

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

2004072907-trunk: works fine
2004073008-trunk: broken

Comment 3

[Andrew Schultz]

bug 252984, perhaps?

Comment 4

[sairuh (rarely reading bugmail)]

Andrew, thanks for tracking that down! the timing of the checkin is right. Aaron?

Comment 5

[Aaron Leventhal]

Attachment: 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">

Comment 6

[Aaron Leventhal]

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.

Comment 7

[[e-mail]]

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.

Comment 8

[Aaron Leventhal]

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.

Comment 9

[Aaron Leventhal]

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

Comment 10

[Aaron Leventhal]

(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

[[e-mail]]

OK, so instead can the creator of the button give it a tabIndex of -1?

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 258015 has been marked as a duplicate of this bug. ***

Comment 13

[Aaron Leventhal]

Attachment: 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.

Comment 14

[[e-mail]]

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...

Comment 15

[Brian Ryner (not reading)]

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.

Comment 16

[Aaron Leventhal]

Attachment: Better place to add attribute

Comment 17

[Aaron Leventhal]

Checking in nsComboboxControlFrame.cpp;
/cvsroot/mozilla/layout/html/forms/src/nsComboboxControlFrame.cpp,v  <-- 
nsComboboxControlFrame.cpp
new revision: 1.294; previous revision: 1.293
done

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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)