WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
210249
[CSS Shadow Parts] Bad style sharing between sibling elements with different part attributes
https://bugs.webkit.org/show_bug.cgi?id=210249
Summary
[CSS Shadow Parts] Bad style sharing between sibling elements with different ...
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: <!-- This div is necessary to trigger the bug --> <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.
Top of Page
Format For Printing
XML
Clone This Bug