RESOLVED FIXED209822
Cannot style ::selection for a flex container
https://bugs.webkit.org/show_bug.cgi?id=209822
Summary Cannot style ::selection for a flex container
adam
Reported 2020-03-31 10:52:07 PDT
See the repro here: https://jsfiddle.net/gs791rx4/8/ Selecting "some text" will show a red backgrounded selection on Chrome but a default selection background on Safari.
Attachments
Patch (34.76 KB, patch)
2020-04-12 21:42 PDT, Tyler Wilcock
no flags
Patch (34.76 KB, patch)
2020-04-12 22:47 PDT, Tyler Wilcock
no flags
Patch (34.79 KB, patch)
2020-05-20 22:48 PDT, Tyler Wilcock
no flags
Patch (34.74 KB, patch)
2020-05-21 10:54 PDT, Tyler Wilcock
no flags
Alexey Proskuryakov
Comment 1 2020-03-31 11:39:10 PDT
<style> .example { display: flex; } .example::selection { background: red !important; } </style> <div class="example"> some text </div>
Radar WebKit Bug Importer
Comment 2 2020-03-31 11:39:19 PDT
Tyler Wilcock
Comment 3 2020-04-05 20:43:27 PDT
Did a little digging into this one. From what I can tell, this is happening because the TextRender's parent is sometimes set as anonymous when it maybe shouldn't be. https://github.com/WebKit/webkit/blob/master/Source/WebCore/rendering/TextPaintStyle.cpp#L161 calls here: https://github.com/WebKit/webkit/blob/master/Source/WebCore/rendering/RenderText.h#L303#L306 eventually calling here, and shortcircuiting `nullptr` in the `isAnonymous()` check: https://github.com/WebKit/webkit/blob/master/Source/WebCore/rendering/RenderElement.cpp#L1407#L1410 Also of note, this behavior is not specific to `display: flex`. See this repro with `display: block` and the introduction of a sibling div. Again, "some text" should be highlighted red, assuming Chrome and Firefox are correct and our behavior is not. Removing the sibling div results in the correct behavior. https://jsfiddle.net/dwuzsmft/ Going to do some more investigation.
Tyler Wilcock
Comment 5 2020-04-12 21:42:01 PDT
Tyler Wilcock
Comment 6 2020-04-12 22:47:57 PDT
Tyler Wilcock
Comment 7 2020-04-13 21:53:25 PDT
I think this should do it. The TLDR is that RenderText unconditionally checks its direct parent for pseudostyles, but the direct parent of text nodes/runs is often anonymous, and pseudostyles are associated with elements of the DOM (i.e., non-anonymous). My proposed patch changes RenderText look for pseudostyles by ascending the tree until a non-anonymous renderer is found. Should be ready for review. I added two test cases. I'm running the GTK port of WebKit, so test expectations were added for LayoutTests/platform/gtk. According to this (https://trac.webkit.org/wiki/CreatingLayoutTests) wiki article, I also need to add test expectations for other platforms. What is the best way to do this? I'm not seeing anything on the Builders page that shows newly generated test expectations as the previous article suggests, but perhaps I'm missing it.
Tyler Wilcock
Comment 8 2020-05-20 22:48:58 PDT
Tyler Wilcock
Comment 9 2020-05-21 07:42:52 PDT
Rebased onto latest master -- tests are still passing.
Antti Koivisto
Comment 10 2020-05-21 08:42:23 PDT
Comment on attachment 399934 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=399934&action=review > Source/WebCore/rendering/RenderObject.cpp:170 > + RenderElement* ancestor = parent(); Could use auto* > Source/WebCore/rendering/RenderText.h:287 > + if (RenderElement* ancestor = firstNonAnonymousAncestor()) Here too > Source/WebCore/rendering/RenderText.h:294 > + if (RenderElement* ancestor = firstNonAnonymousAncestor()) etc
Tyler Wilcock
Comment 11 2020-05-21 10:54:45 PDT
Tyler Wilcock
Comment 12 2020-05-21 15:29:46 PDT
Thanks for the review, Antti. I applied your suggestions in this latest patch and tests are again green. I think my addition of a new patch nullified your r+ -- could you take another look, please?
EWS
Comment 13 2020-05-22 01:34:35 PDT
Committed r262049: <https://trac.webkit.org/changeset/262049> All reviewed patches have been landed. Closing bug and clearing flags on attachment 399968 [details].
Ryan Haddad
Comment 14 2020-05-22 09:41:24 PDT
Added test baselines for macOS and iOS in r262059
Note You need to log in before you can comment on or make changes to this bug.