RESOLVED FIXED Bug 169296
Label of an <option> element should not be displayed in quirks mode 
https://bugs.webkit.org/show_bug.cgi?id=169296
Summary Label of an <option> element should not be displayed in quirks mode
David Kilzer (:ddkilzer)
Reported 2017-03-07 11:42:17 PST
The label of an <option> element is displayed in a <select> menu when the textContent of the <option> element is empty, such as in this example: <select> <option value="X" label="Y"></option> <option value="?">?</option> <option value="+" >+</option> <option value="-" >-</option> </select> This displays the following options in the <select> menu in WebKit: Y ? + - Neither Firefox nor Chrome display the label--instead that item is blank. This matters because a future version of Bugzilla added the label, so WebKit will render the <option> incorrectly until this is fixed: <https://github.com/bugzilla/bugzilla/commit/7d0c10e71498f2909f466fc0ccda1890595bd3ff#diff-535e432916dc0692c5c86efd8da46662L126>
Attachments
Patch (7.81 KB, patch)
2017-03-07 13:18 PST, Chris Dumez 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
David Kilzer (:ddkilzer)
Comment 1 2017-03-07 11:47:37 PST
<rdar://problem/30900751>
Simon Fraser (smfr)
Comment 2 2017-03-07 11:57:04 PST
Our <option> rendering seems to be pretty non-standard in general: bug 169039.
Chris Dumez
Comment 3 2017-03-07 12:04:44 PST
> Label of an <option> element should not be displayed when textContent of the element is empty @David: Do you have a link to a spec that says this is the expected behavior?
Chris Dumez
Comment 4 2017-03-07 12:10:36 PST
(In reply to comment #3) > > Label of an <option> element should not be displayed when textContent of the element is empty > > @David: Do you have a link to a spec that says this is the expected behavior? What I found is: https://html.spec.whatwg.org/multipage/rendering.html#the-select-element-2 which says: "An option element is expected to be rendered by displaying the element's label, indented under its optgroup element if it has one." label points to: https://html.spec.whatwg.org/multipage/forms.html#concept-option-label which says: "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."
Chris Dumez
Comment 5 2017-03-07 12:13:30 PST
(In reply to comment #4) > (In reply to comment #3) > > > Label of an <option> element should not be displayed when textContent of the element is empty > > > > @David: Do you have a link to a spec that says this is the expected behavior? > > What I found is: > https://html.spec.whatwg.org/multipage/rendering.html#the-select-element-2 > > which says: > "An option element is expected to be rendered by displaying the element's > label, indented under its optgroup element if it has one." > > label points to: > https://html.spec.whatwg.org/multipage/forms.html#concept-option-label > > which says: > "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." So as far as I can tell, we match the HTML spec here. If it does not match other browsers, we likely want to file a bug against the HTML spec.
Chris Dumez
Comment 6 2017-03-07 12:18:22 PST
Test case: http://jsbin.com/lodayapaxa/1/edit?html,output I see the 'Y' in WebKit ToT and Chrome Canary. I see an empty label in Firefox nightly. So it seems we agree with the spec and Chrome Canary. Based on David's bug report, Chrome's behavior may have changed recently.
Chris Dumez
Comment 7 2017-03-07 12:21:37 PST
(In reply to comment #6) > Test case: > http://jsbin.com/lodayapaxa/1/edit?html,output > > I see the 'Y' in WebKit ToT and Chrome Canary. I see an empty label in > Firefox nightly. > > So it seems we agree with the spec and Chrome Canary. Based on David's bug > report, Chrome's behavior may have changed recently. Actually, I see the 'Y' in Chrome 56 stable as well so if they changed their behavior, it is not that recent.
Chris Dumez
Comment 8 2017-03-07 12:30:44 PST
Just checked this with Alexey, the difference is that my test has a <!DOCTYPE html> and Alexey's test page does not. So in *Standards* mode, our behavior is standard and consistent with Chrome. However, in quirks mode, our behavior is inconsistent with Chrome and Firefox (i.e. we show the label).
Chris Dumez
Comment 9 2017-03-07 12:34:19 PST
Corresponding Blink code: String HTMLOptionElement::displayLabel() const { Document& document = this->document(); String text; // WinIE does not use the label attribute, so as a quirk, we ignore it. if (!document.inQuirksMode()) text = fastGetAttribute(labelAttr); // FIXME: The following treats an element with the label attribute set to // the empty string the same as an element with no label attribute at all. // Is that correct? If it is, then should the label function work the same // way? if (text.isEmpty()) text = collectOptionInnerText(); return text.stripWhiteSpace(isHTMLSpace<UChar>) .simplifyWhiteSpace(isHTMLSpace<UChar>); } So we're likely missing: // WinIE does not use the label attribute, so as a quirk, we ignore it. if (!document.inQuirksMode()) text = fastGetAttribute(labelAttr);
Chris Dumez
Comment 10 2017-03-07 13:09:42 PST
Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1345242
Chris Dumez
Comment 11 2017-03-07 13:18:48 PST
Created attachment 303712 [details] Patch
WebKit Commit Bot
Comment 12 2017-03-07 14:24:22 PST
Comment on attachment 303712 [details] Patch Clearing flags on attachment: 303712 Committed r213542: <http://trac.webkit.org/changeset/213542>
WebKit Commit Bot
Comment 13 2017-03-07 14:24:28 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.