LABELs don't work for OPTIONs (<option label> in selects) (standards mode only!)
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | verified |
People
(Reporter: ekrock, Assigned: chutten)
References
(Depends on 1 open bug, Blocks 1 open bug, Regressed 1 open bug, )
Details
(4 keywords, Whiteboard: [p-ie/win][p-safari][p-opera] relnote-devel[HTML4-#adef-label-OPTION], [wptsync upstream])
Attachments
(5 files)
Updated•25 years ago
|
Comment 2•25 years ago
|
||
Comment 4•25 years ago
|
||
Comment 6•25 years ago
|
||
Updated•24 years ago
|
Updated•24 years ago
|
Reporter | ||
Comment 8•24 years ago
|
||
Updated•24 years ago
|
Comment 10•24 years ago
|
||
Comment 11•24 years ago
|
||
Comment 12•24 years ago
|
||
Comment 13•23 years ago
|
||
Comment 14•23 years ago
|
||
Updated•23 years ago
|
Updated•23 years ago
|
Updated•23 years ago
|
Comment 15•23 years ago
|
||
Comment 16•22 years ago
|
||
Updated•22 years ago
|
Comment 17•20 years ago
|
||
Comment 18•20 years ago
|
||
Comment 19•20 years ago
|
||
Comment 20•20 years ago
|
||
Comment 21•19 years ago
|
||
Updated•19 years ago
|
Comment 22•19 years ago
|
||
Comment 23•19 years ago
|
||
Comment 24•18 years ago
|
||
Comment 25•17 years ago
|
||
Comment 27•17 years ago
|
||
Comment 28•17 years ago
|
||
Comment 29•15 years ago
|
||
Comment 30•15 years ago
|
||
Comment 42•9 years ago
|
||
Comment 43•9 years ago
|
||
Comment 44•9 years ago
|
||
Comment 45•9 years ago
|
||
Updated•9 years ago
|
Comment 46•9 years ago
|
||
Comment 47•9 years ago
|
||
Comment 48•9 years ago
|
||
Comment 49•8 years ago
|
||
Comment 53•7 years ago
|
||
Comment 54•7 years ago
|
||
Comment 55•7 years ago
|
||
Comment 56•6 years ago
|
||
Comment 57•6 years ago
|
||
Comment 58•5 years ago
|
||
Current test case/additional info: https://scottaohara.github.io/tests/html-select/label-value-attrs.html
Firefox 68.0.1 on macOS / Windows 10 do not render label. Firefox on Android does render the label.
Assignee | ||
Comment 59•5 years ago
|
||
According to spec, option elements with label attributes should show and use
those labels rather than their element text. So let's do that.
Requires some trickery because the option element is a block element (so it
lays out its width based on its text content) so we put its label (if it has
one) in its ::before and skip frame generation so it measures the text of its
label, not of its text node children.
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Comment 60•5 years ago
|
||
Hi chutten! Thanks for looking into this. I suspect it belongs as P3 rather than P1, given that we've let it go unfixed for so long. (In layout, P3 = normal-priority bug, while P1=must-fix-ASAP,possibly-need-to-uplift-the-fix. And I think this is in the former category).
--> Adjusting priority, but let me know if I've missed something & this is super-high-priority for some reason.
Assignee | ||
Comment 61•5 years ago
|
||
Nope, that's cool. In Telemetry Land P1 is "working on it presently" and P3 is "intending to work on it this quarter" (full list at the bottom of this page), which is where the mismatch is : )
Updated•5 years ago
|
Comment 62•5 years ago
|
||
Comment 66•5 years ago
|
||
Backed out changeset 813e1405e501 (bug 40545) for Android failures at test_bug659596.html
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=295782370&repo=autoland&lineNumber=3102
Backout: https://hg.mozilla.org/integration/autoland/rev/3b4a2d668c0a4ab05ccd584701cd063d768dd0e3
Assignee | ||
Comment 67•5 years ago
|
||
Well this is interesting. The failing test is checking that option.label
is the same value as option.getAttribute("label")
. With my change option.label
is correct wrt spec in that it returns the value of option.text
if it's set to the empty string... should getAttribute("label")
return the same value?
Comment 68•5 years ago
|
||
No, getAttribute should just return the attribute value. I think the test is right. I don't think label=""
should return the text if it's empty:
https://html.spec.whatwg.org/multipage/form-elements.html#dom-option-label says:
The label IDL attribute, on getting, if there is a label content attribute, must return that attribute's value; otherwise, it must return the element's label. On setting, the element's label content attribute must be set to the new value.
label=""
means that there is an attribute, even if it's the empty string. So this is a bug on the patch, and we should use something else to get the "rendered" text other than GetLabel
.
Assignee | ||
Comment 69•5 years ago
•
|
||
Doesn't option
's definition for the label
attribute supercede the generic one for form elements, in this case?
The label attribute provides a label for element. The label of an option element is the value of the label content attribute, if there is one and its value is not the empty string, or, otherwise, the value of the element's text IDL attribute.
Comment 70•5 years ago
|
||
No, the content attribute is just the attribute on the element, what getAttribute
returns.
Comment 71•5 years ago
|
||
(other browsers also seem to agree with this)
Assignee | ||
Comment 72•5 years ago
|
||
Okay, so it seems as though the consensus is that the label content attribute and IDL should agree with each other (which is to say, should be allowed to return "" and null even if there's text content) and the "label" that Option's part of the spec is talking about is some render-only label concept to help explain the visual behaviour.
Gonna have to rewrite some stuff : |
Comment 73•5 years ago
|
||
Also seeing option-label.html failures starting with the backed out changes:
https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=os%2Cx%2C10.14%2Cshippable%2Copt%2Cweb%2Cplatform%2Ctests%2Ctest-macosx1014-64-shippable%2Fopt-web-platform-tests-e10s-3%2Cw%28wpt3%29&fromchange=bb7b5139b10bee745798181e1f313a4f34ff80b0&tochange=3b4a2d668c0a4ab05ccd584701cd063d768dd0e3&selectedJob=295819535
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=295819535&repo=autoland&lineNumber=7288
Updated•5 years ago
|
Comment 74•5 years ago
|
||
Comment 76•5 years ago
|
||
And rename GetRenderLabel to GetRenderedLabel, as it's a slightly more
descriptive name IMHO.
Comment 77•5 years ago
|
||
Comment 78•5 years ago
|
||
Comment 79•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/41906e11f2d2
https://hg.mozilla.org/mozilla-central/rev/6c29976af974
https://hg.mozilla.org/mozilla-central/rev/bb80f48dfd8d
Comment 80•5 years ago
|
||
I can confirm that in Firefox 75.0 the attribute is ignored while in Nightly 77.0a1 (2020-04-07) it is recognized as expected.
Thank you for implementing this and congrats on fixing a twenty years old bug!
Sebastian
Comment 82•5 years ago
|
||
Question: The "Milestone" field should be set to "mozilla77", right?
Sebastian
Assignee | ||
Comment 83•5 years ago
|
||
According to the docs that's a sheriff-managed field, so I'm not gonna touch it : )
Updated•5 years ago
|
Updated•4 years ago
|
Description
•