1240285 - <label> element with tabindex attribute should become focused when element.focus() is called on it (and not forward focus to its control element)

Status: RESOLVED FIXED

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

Description

[Rodney Rehm]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20160105164030

Steps to reproduce:

1. create HTML fragment: <label tabindex="0" for="target"><input id="target">
2. click on the label and see focus is forwarded to the input
3. click on the document, then press the tab key and see that the label itself is focused

test case: http://jsbin.com/zotugibuho/1/edit?html,css,output


Actual results:

the label element got focus


Expected results:

the label should not have gotten focus, because it shouldn't have been part of the document's sequential navigation focus order.

Comment 1

[Mats Palmgren (inactive)]

I don't see any support for your expected results in the spec.
There is no exception for label elements there AFAICT.
Please point it out if I missed it.
https://html.spec.whatwg.org/multipage/interaction.html#attr-tabindex

Chrome and IE11 behaves the same way as Firefox, so I don't think
we should change this unless there is first a HTML spec change
that describes the suggested new behavior for label elements.

Comment 2

[Rodney Rehm]

The specification does not mention this particular case. Chrome does not add the label to the tabbing sequence, but it seems IE11 and Edge 12 do. I opened the issue believing Firefox was the only browser exhibiting this behavior - I was wrong, so this issue should probably be closed, sorry.

Comment 3

[Rodney Rehm]

Ah, now I see why the IE11 thing escaped me.

For the record, IE11 does not forward focus to the referenced input element, if the label is made focusable via adding a tabindex. This is not the case in Firefox. Click and script focus forward focus to the input element, while keyboard focus shifts focus to the label element itself. In Chrome the label element does not become keyboard focusable.

I think that Firefox should align the behavior of script-, click- and keyboard-focus.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase #2

I get the same results in Firefox, Chrome and IE11 when:
1. tabbing to the label - the focus stays on the <label> element
2. clicking on "Label:" - first the <label> is
   focused (on mousedown) then the <input> is focused (on mouseup)

I get different results when:
3. focusing the <label> via script: document.querySelector('label').focus())
   (click the "label.focus()" button)
In Firefox: the <input> is focused.
In IE11 and Chrome the <label> is focused.

Comment 5

[Mats Palmgren (inactive)]

The relevant spec sections for focus():
https://html.spec.whatwg.org/multipage/interaction.html#dom-focus
https://html.spec.whatwg.org/multipage/interaction.html#focusing-steps
https://html.spec.whatwg.org/multipage/interaction.html#focus-update-steps
and the section on <label>:
https://html.spec.whatwg.org/multipage/forms.html#the-label-element

I don't see anything there that makes an exception for <label> when
it is an /focusable area/ (e.g. when it has tabindex="0") so I think
Chrome and IE11 is correct for case 3 above.

So that seems like a bug in Firefox.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Not sure if it was about this case where the spec was buggy when dealing with focus and <label>. Better to check if there is related spec bug.

Comment 7

[Paul LeBeau]

Here's another (even simpler) test case.

https://jsfiddle.net/gqo5erxs/

The label gets focus on Chrome and IE. But doesn't in FF.


The reason I found this bug was because I had a custom styled checkbox where the <input> element is made transparent and the label gets some custom checkbox styling.  AFAIK this is a very common approach to applying a custom style to radio and checkbox inputs.  Unfortunately my accessibility behaviour is broken in FF because I can't focus the label when I need to (eg. on error etc).

Comment 9

[Mu-An Chiou (muan)]

Just want to add a note to say that we ran into this problem recently at GitHub. On repository creation page: https://github.com/new, the repository owner dropdown menu uses `label[tabindex=0]` + `.focus()` to provide keyboard navigation support with ArrowUp and ArrowDown. This works in IE11/Edge/Chrome/Safari, but sadly not in Firefox.

Comment 11

[Edgar Chen [:edgar]]

Anne, do you know if <label> + focus is something valid in spec or is there any spec bug around this? Please see comment #5 and comment #6, Thanks.

Comment 12

[Anne (:annevk)]

I can't find a related specification bug and per the specification label only "transfers" focus when activated (i.e., its activation behavior; click) so I think Mats is correct about the bug mentioned in comment 5.

It does seem to me that the label should be part of the tabbing order and as far as I can tell it is in both Chrome and Firefox (on macOS), so comment 0 does not seem like a bug to me.

Comment 13

[Mu-An Chiou (muan)]

Any chance for this to be fixed now that https://bugzilla.mozilla.org/show_bug.cgi?id=1240285#c5 is confirmed a bug?

We have been receiving more reports about this, and there is no real workaround other than to not use <label>, which is unideal as it means we will have to refactor uses of label related APIs like the input.label association, and mimic the activation behavior with other elements.

Please let me know if there's anything we can do to help. Thanks.

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

It looks like Gecko always redirect the focus because it implements HTMLLabelElement::Focus() and overloads the base class.

https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/dom/html/HTMLLabelElement.cpp#53

It's doesn't seems that the native click handling would call this method to "redirect" the focus? Should this method simply be removed since programmatically focus shouldn't be redirected?

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Talked to :edgar offline and he can mentor this bug. I've given muan some pointers for information on setting up the dev environment.

Comment 16

[Edgar Chen [:edgar]]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #14)

It's doesn't seem that the native click handling would call this method to "redirect" the focus?

No, the native click handling would not call HTMLLabelElement::Focus() to redirect focus, it is handled in https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/dom/html/HTMLLabelElement.cpp#145-149.

Should this method simply be removed since programmatically focus shouldn't be redirected?

Yes, it seems the overloaded method could be removed.

Comment 17

[David Graham]

Attachment: Bug 1240285 - Forward focus only if label is not focusable r=edgar

Focus should remain on the label rather than forwarded to the labeled
element.

Co-Authored-By: Mu-An Chiou <[e-mail]>

Comment 18

[Mats Palmgren (inactive)]

Attachment: Testcase #3

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/242188be2948
Forward focus only if label is not focusable r=edgar

Comment 20

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/22449 for changes under testing/web-platform/tests

Comment 21

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 22

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/242188be2948

Comment 23

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot