Closed Bug 1448791 Opened 2 years ago Closed 2 years ago
[wpt-sync] Sync PR 10174 - Keep track of all pending slot assignments, and recalc all before Update
Sync web-platform-tests PR 10174 into mozilla-central (this bug is closed when the sync is complete). PR: https://github.com/w3c/web-platform-tests/pull/10174 Details from upstream follow. Hayato Ito <email@example.com> wrote: > Keep track of all pending slot assignments, and recalc all before UpdateStyle phase > > For the purpose of rendering, Blink must calculate all pending slot assignments > before UpdateStyle phase. Unless that, a recursive RecalcStyle() may not > traverse a node which should be re-attached. > > e.g. Suppose the following tree, where #d1 is assigned to a slot. > > host > ├──/shadow-root > │ └── slot name=s1 > └── div id=d1 slot=s1 > > Then, we change #d1's slot attribute to s2, like: > > > document.querySelector('#d1').setAttribute('slot', 's2'); > > host > ├──/shadow-root > │ └── slot name=s1 > └── div id=d1 slot=s2 > > In this case, #d1 should be removed from a LayoutTree. In other words, Blink > has to reattach #d1 somehow. However, if we don't recalc a slot assignment for > the shadow tree before UpdateStyle, a recursive RecalcStyle never traverses the > sub-tree because child-needs-style-recalc flag is not set for the node (and its > ancestor noes). A flag should be set as a result of slot assignment recalc. > > Thanks to the Incremental Shadow DOM, a slot assignemt recalc now becomes a > local operatoin on each shadow tree, rather than one global operation for every > shadow trees. We don't need to traverse a composed tree to recalc all. We can > recalc a slot assignment for each shadow tree directly, without traversing a > composed tree. > > For a shadow tree which is not connected, we don't need to recalc its slot > assignment before UpdateStyle because such a shadow tree shouldn't have any > effect on rendering. Lazy slot assignment recalc is enough for such a shadow > tree. > > This CL doesn't introduce any optimization to minimize the number of > to-be-reattached nodes. I'll optimize that as a next task. I'll use a sort of > dynamic programming there, as I did at > https://chromium-review.googlesource.com/c/chromium/src/+/535493 for > non-Incremental Shadow DOM. > > Except for the performance, this CL should be the last part of Incremental > Shadow DOM from the external behavior's perspective. Style and Layout should > work correctly after this CL, even with Incremental Shadow DOM. > > BUG=776656 > > Change-Id: Id18e87ff59d92863c68c571e7db09253c08aa91f > Reviewed-on: https://chromium-review.googlesource.com/964062 > WPT-Export-Revision: b186a1fe85672e9d484ea148d090c9e07c97c779
Component: web-platform-tests → DOM
Product: Testing → Core
Pushed to try (stability) https://treeherder.mozilla.org/#/jobs?repo=try&revision=de7e2af733d189446d77b9c311093079d0317530
P4 is unused to setting priority to P3.
Priority: P4 → P3
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/47729ad34d0c [wpt PR 10174] - Keep track of all pending slot assignments, and recalc all before UpdateStyle phase, a=testonly
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.