Closed Bug 1577592 Opened 3 months ago Closed 3 months ago

Shadow Parts seem to not match ::part when a document fragment with [part] elements inside of it is imported into a shadow root

Categories

(Core :: CSS Parsing and Computation, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: bgrins, Assigned: emilio)

References

Details

Attachments

(3 files)

Details here: https://phabricator.services.mozilla.com/D43846#1324342.

When I remove and re-add the [part] attribute, the selector starts matching again.

See Also: → 1573158

Any chance you could write a stand-alone test-case? Happy to fix ASAP :)

Blocks: shadow-parts
Flags: needinfo?(bgrinstead)
Priority: -- → P3

This was my first attempt to have a reduced test case in content but it is working properly. I guess a couple more things to test are loading this same thing but with the style in an external chrome sheet and then also using XUL elements instead.

It seems somehow XUL and/or XBL related - I've pushed up a more reduced mochitest-chrome test that fails.

Flags: needinfo?(bgrinstead)

Thanks, I'll take a look first thing tomorrow morning :)

Flags: needinfo?(emilio)

I actually just took a look, whoops... It's indeed a XUL bug.

Assignee: nobody → emilio
Flags: needinfo?(emilio)

Test is in the other revision for this bug.

Do the same we do for the other bits. This setup looks pretty error prone
though...

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b78fd9e42adc
Properly set the has part attribute bit when cloning a XUL element. r=bzbarsky
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a334d3b33b26
Test case for Shadow Parts not applying with fragment containing XUL element r=emilio
See Also: → 1577721
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
You need to log in before you can comment on or make changes to this bug.