Bug 169296 - Label of an <option> element should not be displayed in quirks mode
Summary: Label of an <option> element should not be displayed in quirks mode
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: Safari 10
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL: data:text/html,<select><option%20valu...
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-03-07 11:42 PST by David Kilzer (:ddkilzer)
Modified: 2017-03-07 14:24 PST (History)
8 users (show)

See Also:


Attachments
Patch (7.81 KB, patch)
2017-03-07 13:18 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Kilzer (:ddkilzer) 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>
Comment 1 David Kilzer (:ddkilzer) 2017-03-07 11:47:37 PST
<rdar://problem/30900751>
Comment 2 Simon Fraser (smfr) 2017-03-07 11:57:04 PST
Our <option> rendering seems to be pretty non-standard in general: bug 169039.
Comment 3 Chris Dumez 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?
Comment 4 Chris Dumez 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."
Comment 5 Chris Dumez 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.
Comment 6 Chris Dumez 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.
Comment 7 Chris Dumez 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.
Comment 8 Chris Dumez 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).
Comment 9 Chris Dumez 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);
Comment 10 Chris Dumez 2017-03-07 13:09:42 PST
Firefox bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1345242
Comment 11 Chris Dumez 2017-03-07 13:18:48 PST
Created attachment 303712 [details]
Patch
Comment 12 WebKit Commit Bot 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>
Comment 13 WebKit Commit Bot 2017-03-07 14:24:28 PST
All reviewed patches have been landed.  Closing bug.