Bug 191581

Summary: Hidden attribute does not apply to optgroup and option
Product: WebKit Reporter: Dev Eloper <develop>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: bfulgham, cdumez, koivisto, rniwa, simon.fraser, webkit-bug-importer, wenson_hsieh, zalan
Priority: P2 Keywords: InRadar
Version: Safari 12   
Hardware: Mac   
OS: macOS 10.13   
URL: https://html.spec.whatwg.org/multipage/rendering.html#the-select-element-2
See Also: https://bugs.webkit.org/show_bug.cgi?id=169039

Description Dev Eloper 2018-11-13 00:49:42 PST 
The spec defines[0] on all HTML elements (subclasses of HTMLElement), including optgroup (HTMLOptGroupElement) and option (HTMLOptionElement) a hidden attribute.
Unlike Firefox, Edge, and Chrome, Safari does not (visually) reflect the semantics of setting this attribute: "User agents should not render elements that have the hidden attribute specified."
In the following demo, optgroup and option are visible in Safari: http://jsfiddle.net/c1nzxm8e/

[0] https://html.spec.whatwg.org/multipage/interaction.html#the-hidden-attribute
Comment 1 Chris Dumez 2018-11-13 08:57:32 PST 
Web Inspector properly reports that both the <option> and <optgroup> have "display: none" computed style, yet they are indeed visible :/

If I add "hidden" attribute the the <select> element then the <select> also becomes "display: none", and then it becomes indeed hidden.

The issue is therefore specific to <option> and <optgroup> elements somehow. Also, I do not believe this is actually a DOM/HTML issue since the CSS style was properly set. This is more likely a CSS or rendering issue.
Comment 2 Chris Dumez 2018-11-13 08:59:56 PST 
Both HTMLOptionElement and HTMLOptGroupElement have the following override:
bool rendererIsNeeded(const RenderStyle&) final { return false; }

Not sure why they do not need a renderer.
Comment 3 Chris Dumez 2018-11-13 09:04:38 PST 
The default definition of rendererIsNeeded is:
bool Element::rendererIsNeeded(const RenderStyle& style)
{
    return style.display() != DisplayType::None && style.display() != DisplayType::Contents;
}
Comment 4 Chris Dumez 2018-11-13 09:09:10 PST 
This may also be relevant:
bool HTMLSelectElement::childShouldCreateRenderer(const Node& child) const
{
    if (!HTMLFormControlElementWithState::childShouldCreateRenderer(child))
        return false;
#if !PLATFORM(IOS_FAMILY)
    if (!usesMenuList())
        return is<HTMLOptionElement>(child) || is<HTMLOptGroupElement>(child) || validationMessageShadowTreeContains(child);
#endif
    return validationMessageShadowTreeContains(child);
}
Comment 5 Simon Fraser (smfr) 2018-11-13 09:18:16 PST 
See also bug 169039. Our <option> rendering seems wonky.
Comment 6 Chris Dumez 2018-11-13 09:22:34 PST 
Relevant rendering code seems to be in void RenderListBox::updateFromElement().
It grabs text from options and optgroup elements without taking into consideration their visibility.
Comment 7 Chris Dumez 2018-11-13 09:25:08 PST 
Moving to Layout & Rendering. I do not think I am the right assignee.
Comment 8 Radar WebKit Bug Importer 2019-07-24 11:36:42 PDT 
<rdar://problem/53505809>
Comment 9 Alexey Proskuryakov 2020-12-06 10:59:44 PST 

*** This bug has been marked as a duplicate of bug 69014 ***