Closed Bug 1842109 Opened 1 year ago Closed 1 year ago

[wpt-sync] Sync PR 40909 - Add `clone` to DocumentPartRoot

Categories

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

task

Tracking

()

RESOLVED FIXED
117 Branch
Tracking Status
firefox117 --- fixed

People

(Reporter: wpt-sync, Unassigned)

References

()

Details

(Whiteboard: [wptsync downstream])

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

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

Mason Freed <masonf@chromium.org> wrote:

Add clone to DocumentPartRoot

You can now clone a DocumentPartRoot, and it will a) clone the
underlying document or document_fragment, b) clone all contained Part
references from the original to the clone, and c) return you the new
DocumentPartRoot. To allow access to the underlying cloned Node tree, I
also added a DocumentPartRoot.root, which returns the owning Document
or DocumentFragment.

So:
const root = document.getPartRoot();
{ ... add NodePart's and ChildNodePart's to root ... }
const clonedPartRoot = root.clone();
const clonedDocument = clonedPartRoot.root;

To make this work, during cloning (via partRoot.clone), references
are kept in NodeCloningData that point from cloned Nodes to their
clones, and from cloned PartRoots to their clones. Also, a "queue"
of to-be-cloned Parts, keyed by the PartRoot they're waiting for,
is used to handle the common case that the PartRoot for one part
might not be cloned before a Part that refers to it. An example is:

\<div id=parent>
\<div id=previous_sibling>\</div>
\<div id=middle>\</div>
\<div id=next_sibling>\</div>
\</div>

Assume there is a ChildNodePart with previous_sibling/next_sibling,
and a NodePart pointing to middle which has ChildNodePart as its
PartRoot. During the clone of this tree, the ChildNodePart can only
be cloned once parent, previous_sibling, and next_sibling have all
been cloned. However, middle (and its NodePart) will get reached by
the clone operation before next_sibling. So NodePart here needs to
be queued and retried once ChildNodePart is cloned.

Bug: 1453291
Change-Id: I4a85c3ee02547627bcf73ed610310c742238f12c
Reviewed-on: https://chromium-review.googlesource.com/4671112
WPT-Export-Revision: 6f4e6de037f2905873184031962ee0e316b09b26

PR 40909 applied with additional changes from upstream: c11f3d0e5c8f13ecee6e0a458fa997e1e46896a4
Component: web-platform-tests → DOM: Core & HTML
Product: Testing → Core

CI Results

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

Total 1 tests and 5 subtests

Status Summary

Firefox

OK : 1
FAIL: 5

Chrome

OK : 1
PASS: 1
FAIL: 4

Safari

OK : 1
FAIL: 5

Links

Gecko CI (Treeherder)
GitHub PR Head
GitHub PR Base

Details

New Tests That Don't Pass

  • /dom/parts/basic-dom-part-objects.tentative.html [wpt.fyi]
    • Basic imperative DOM Parts object construction (Document): FAIL (Chrome: FAIL, Safari: FAIL)
    • Cloning (Document): FAIL (Chrome: FAIL, Safari: FAIL)
    • Basic imperative DOM Parts object construction (DocumentFragment): FAIL (Chrome: FAIL, Safari: FAIL)
    • Cloning (DocumentFragment): FAIL (Chrome: FAIL, Safari: FAIL)
    • DOM mutation support: FAIL (Chrome: PASS, Safari: FAIL)
Pushed by wptsync@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/956ee3986f86 [wpt PR 40909] - Add `clone` to DocumentPartRoot, a=testonly https://hg.mozilla.org/integration/autoland/rev/bde625166179 [wpt PR 40909] - Update wpt metadata, a=testonly
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 117 Branch
You need to log in before you can comment on or make changes to this bug.