Bug 188259 – Toggling "display: contents" to "display: none" fails to hide the element

• Component: CSS
• Status: RESOLVED FIXED

[Daniel Sieradski]

Created attachment 346382 [details]
screenshot of bug

I have an element that's default setting is "display: none;".

When the page first loads, it is properly hidden.

Then, using a JavaScript click event, the element style is changed to "display: contents;", showing the hidden content.

Clicking a close button should re-hide the content with an event that removes the "display: contents;" from the element style, returning it to its default state of "display: none;".

This works properly in Firefox and Chrome on desktop and iOS.

However in Safari on desktop and iOS, as well as Chrome on iOS, when you click the close button, WebKit properly removes "display: contents;" and returns to the state of "display: none;" but the element itself that should be hidden still appears on screen.

In the attached screenshot, you will see that the element highlighted in the devtools elements pane ("#award--body") is shown as "display: none;" in the styles panel, but still appears on screen.

You can see the bug in action here: https://youtu.be/B9fJP4BoijU.

[Daniel Sieradski]

The URL where you can tinker with this is:
https://nylon.com/articles/nylon-beauty-hit-list-awards-2018

[Daniel Sieradski]

Sorry, I meant to write, "This works properly in Firefox and Chrome on desktop." It also works in Edge.

[Daniel Sieradski]

This appears to be specifically related to the use of "display: contents;". If I switch it to "display: block;" then it works fine.

[Saam Barati]

Hi Daniel, thanks for the bug report. I’ve CCd some folks who should be able to figure out what’s going on

[Simon Fraser (smfr)]

display:contents bug.

[Radar WebKit Bug Importer]

<rdar://problem/42886896>

[Antti Koivisto]

I can't reproduce with that page, it doesn't appear to use display:contents. Daniel, do you have a test case for this?

[Daniel Sieradski]

Sorry, once I figured out a fix, I had to implement it. I can put a rolled-back version up on a staging server if you only need it for a little bit.

[Simon Fraser (smfr)]

Please do (or make a small test case if you can).

[Eloy Duran]

You can find a reproduction here https://codepen.io/alloy/pen/rQWmYG. Resize the width of the window to see that on Safari all elements stay visible, once visible. On Chrome only 1 element is visible at a time.

[Eloy Duran]

Btw, I’m seeing this on Safari 12 and the TP build of November 7th.

[Ryosuke Niwa]

Yeah, I can reproduce the problem now.

[Eric Gao]

Any progress on this? I have made a CodePen with a far simpler test case. https://codepen.io/ericxgao/pen/dreqWp

Go in and inspect the text in Safari 12 - changing the class from "contents" to "hide" does nothing.

[Ryosuke Niwa]

Created attachment 365065 [details]
Reduction

[Ryosuke Niwa]

Created attachment 365066 [details]
Even simpler reduction

[Antti Koivisto]

Created attachment 365857 [details]
patch

[EWS Watchlist]

Comment on attachment 365857 [details]
patch

Attachment 365857 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/11659182

New failing tests:
http/tests/preload/download_resources_from_header_iframe.html

[EWS Watchlist]

Created attachment 365859 [details]
Archive of layout-test-results from ews202 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews202  Port: win-future  Platform: CYGWIN_NT-6.1-2.10.0-0.325-5-3-x86_64-64bit

[WebKit Commit Bot]

Comment on attachment 365857 [details]
patch

Clearing flags on attachment: 365857

Committed r243444: <https://trac.webkit.org/changeset/243444>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.