Bug 210249

Summary:

[CSS Shadow Parts] Bad style sharing between sibling elements with different part attributes

Product:

WebKit

Reporter:

Justin Fagnani <justin>

Component:

CSS

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Major

CC:

emilio, iamkulykov, koivisto, rniwa, simon.fraser, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

WebKit Nightly Build

Hardware:

All

OS:

All

Bug Depends on:

Bug Blocks:

148695

Attachments:

Description	Flags
patch	none
patch	none

Justin Fagnani

Reported 2020-04-08 23:24:22 PDT

The ::part() selector released in 13.1, and as currently implemented in TP and nightly, is selecting the wrong elements when parts are nested in any container element in a shadow root. Given this DOM:  <div> <span part="one">Should be Blue</span> | <span part="two">Should be Red</span> </div> And these selectors: my-element::part(one) { color: blue; } my-element::part(two) { color: red; } The text spans should be blue then red as described. Instead they are both blue. If the <div> is removed, or if the second <span> is changed to a different tag, the colors are correct. JS Bin: https://jsbin.com/bucejul/3/edit

Attachments
patch (4.12 KB, patch) 2020-04-10 07:14 PDT, Antti Koivisto	no flags	Details Formatted Diff Diff
patch (4.08 KB, patch) 2020-04-10 07:54 PDT, Antti Koivisto	no flags	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Serhii Kulykov

Comment 1 2020-04-09 00:31:04 PDT

Setting style attribute, e.g. display, or direction attribute on part="two", also forces the red color to apply.

Radar WebKit Bug Importer

Comment 2 2020-04-09 16:10:25 PDT

<rdar://problem/61547528>

Emilio Cobos Álvarez (:emilio)

Comment 3 2020-04-10 06:15:22 PDT

That smells a lot like broken style sharing. Firefox had a somewhat similar bug in fact: https://bugzilla.mozilla.org/show_bug.cgi?id=1604989

Antti Koivisto

Comment 4 2020-04-10 06:46:26 PDT

Yeah, bet that's the problem. Those spans are obvious style sharing candidates if you forget about 'part'.

Antti Koivisto

Comment 5 2020-04-10 07:14:40 PDT

Created attachment 396079 [details] patch

Antti Koivisto

Comment 6 2020-04-10 07:54:24 PDT

Created attachment 396082 [details] patch

Daniel Bates

Comment 7 2020-04-10 07:57:00 PDT

Comment on attachment 396082 [details] patch Make sense to me,

EWS

Comment 8 2020-04-10 09:13:47 PDT

Committed r259877: <https://trac.webkit.org/changeset/259877> All reviewed patches have been landed. Closing bug and clearing flags on attachment 396082 [details].

Justin Fagnani

Comment 9 2020-04-10 10:33:25 PDT

Thanks for the really quick turnaround!

Justin Fagnani

Comment 10 2020-04-10 10:48:56 PDT

A question about the release process for bug fixes like this: will this go out in a patch release on 13.1, or the next big release? ie, will we have to tell developers to use a ::part() polyfill until 13.2?

Ryosuke Niwa

Comment 11 2020-04-10 11:02:18 PDT

(In reply to Justin Fagnani from comment #10) > A question about the release process for bug fixes like this: will this go > out in a patch release on 13.1, or the next big release? ie, will we have to > tell developers to use a ::part() polyfill until 13.2? It’s unlikely that a bug fix like this makes it to a software update unless there is a major site that’s been actively affected.

Antti Koivisto

Comment 12 2020-07-03 03:27:11 PDT

FYI, this fix is in the current macOS 10.15.6/iOS 13.6 public beta.

Note You need to log in before you can comment on or make changes to this bug.