1705465 - [wpt-sync] Sync PR 28521 - Implement imperative slotting API changes

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, task, P4)

Description

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Sync web-platform-tests PR 28521 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/28521
Details from upstream follow.

b'Mason Freed <[e-mail]>' wrote:

Implement imperative slotting API changes

The original implementation of the imperative slot distribution
API was done before the final spec PRs landed. In the process of
landing those PRs, several changes were made to the way the API
works. Primarily, there are two changes:

1. The "auto" slotAssignment mode was renamed to "named".
2. The "linkage" that is created by HTMLSlotElement.assign() was
   made more permanent. Previously, moving either the \<slot> or
   the assigned node around in the tree (or across documents)
   would "break" the linkage. Now, the linkage is more permanent,
   and the only way to break it is through another call to .assign().

See [1] for the chromestatus entry, [2] for the intent to ship,
[3], [4], and [5] for the spec PRs, and [6]/[7] for the landed spec.

[1] https://chromestatus.com/feature/4979822998585344
[2] https://groups.google.com/a/chromium.org/g/blink-dev/c/6U78F3KWJ78
[3] https://github.com/whatwg/html/pull/6561
[4] https://github.com/whatwg/html/pull/6585
[5] https://github.com/whatwg/dom/pull/966
[6] https://dom.spec.whatwg.org/#find-slotables
[7] https://html.spec.whatwg.org/#dom-slot-assign

Fixed: 1196842
Fixed: 1067153
Bug: 1067157
Change-Id: I0ee71043c23f3b49a1461296d722045f06eca540

Reviewed-on: https://chromium-review.googlesource.com/2824763
WPT-Export-Revision: ef0db71d457dec42232532a1ef0c76cddca230c9

Comment 1

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Pushed to try (stability) https://treeherder.mozilla.org/#/jobs?repo=try&revision=cde9eb2926b83234c26de2b80b7e5d09d9332400

Comment 2

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

CI Results

Ran 15 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI

Total 2 tests and 14 subtests

Status Summary

Firefox

OK : 2
FAIL: 26

Chrome

OK : 2
PASS: 21
FAIL: 5

Safari

OK : 2
FAIL: 26

Links

Gecko CI (Treeherder)
GitHub PR Head
GitHub PR Base

Details

New Tests That Don't Pass

/shadow-dom/imperative-slot-api-slotchange.html
slotchange event must not fire synchronously.: FAIL (Chrome: PASS, Safari: FAIL)
slotchange event should not fire when assignments do not change assignedNodes.: FAIL (Chrome: PASS, Safari: FAIL)
slotchange event should not fire when same node is assigned.: FAIL (Chrome: PASS, Safari: FAIL)
Fire slotchange event when slot's assigned nodes changes.: FAIL (Chrome: PASS, Safari: FAIL)
Fire slotchange event on previous slot and new slot when node is reassigned.: FAIL (Chrome: PASS, Safari: FAIL)
Fire slotchange event on node assignment and when assigned node is removed.: FAIL (Chrome: PASS, Safari: FAIL)
Fire slotchange event when order of assigned nodes changes.: FAIL (Chrome: PASS, Safari: FAIL)
Fire slotchange event when assigned node is removed.: FAIL (Chrome: PASS, Safari: FAIL)
Fire slotchange event when removing a slot from Shadows Root that changes its assigned nodes.: FAIL (Chrome: PASS, Safari: FAIL)
No slotchange event when adding or removing an empty slot.: FAIL (Chrome: PASS, Safari: FAIL)
No slotchange event when adding another slotable.: FAIL (Chrome: PASS, Safari: FAIL)
Fire slotchange event when assign node to nested slot, ensure event bubbles ups.: FAIL (Chrome: PASS, Safari: FAIL)
/shadow-dom/imperative-slot-api.html
attachShadow can take slotAssignment parameter.: FAIL (Chrome: FAIL, Safari: FAIL)
Imperative slot API can assign nodes in manual slot assignment.: FAIL (Chrome: PASS, Safari: FAIL)
Order of slottables is preserved in manual slot assignment.: FAIL (Chrome: PASS, Safari: FAIL)
Previously assigned slottable is moved to new slot when it's reassigned.: FAIL (Chrome: PASS, Safari: FAIL)
Order and assignment of nodes are preserved during multiple assignment in a row.: FAIL (Chrome: PASS, Safari: FAIL)
Assigning invalid nodes should be allowed.: FAIL (Chrome: FAIL, Safari: FAIL)
Moving a slot to a new host, the slot loses its previously assigned slottables.: FAIL (Chrome: PASS, Safari: FAIL)
Moving a slot's tree order position within a shadow host has no impact on its assigned slottables.: FAIL (Chrome: PASS, Safari: FAIL)
Appending slottable to different host, it loses slot assignment. It can be re-assigned within a new host.: FAIL (Chrome: PASS, Safari: FAIL)
Previously assigned node should not be assigned if slot moved to a new shadow root. The slot remains empty when moved back, trigger recalc.: FAIL (Chrome: PASS, Safari: FAIL)
Assignment with the same node in parameters should be ignored, first one wins.: FAIL (Chrome: FAIL, Safari: FAIL)
Removing a slot from DOM resets its slottable's slot assignment.: FAIL (Chrome: PASS, Safari: FAIL)
Nodes can be assigned even if slots or nodes aren't in the same tree.: FAIL (Chrome: FAIL, Safari: FAIL)
Removing a node from the document does not break manually assigned slot linkage.: FAIL (Chrome: FAIL, Safari: FAIL)

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ec2fece343c2
[wpt PR 28521] - Implement imperative slotting API changes, a=testonly
https://hg.mozilla.org/integration/autoland/rev/cb8df8aad0f7
[wpt PR 28521] - Update wpt metadata, a=testonly

Comment 4

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/ec2fece343c2
https://hg.mozilla.org/mozilla-central/rev/cb8df8aad0f7