Implement DOM.resolveNode
Categories
(Remote Protocol :: CDP, task, P1)
Tracking
(firefox76 fixed)
| Tracking | Status | |
|---|---|---|
| firefox76 | --- | fixed |
People
(Reporter: whimboo, Assigned: whimboo)
References
()
Details
(Whiteboard: [puppeteer-beta-mvp])
Attachments
(2 files, 1 obsolete file)
Before we get this API implemented bug 1607560 is required because Puppeteer depends on it's returned backendNodeId.
|
||
Updated•5 years ago
|
Yes, and as noted on bug 1607560, the implementation of resolveNode also depends on writing an element store.
|
Assignee | |
Comment 2•5 years ago
|
||
This needs to be kept as P2 given that it has a very high usage, which is identical to DOM.describeNode (bug 1607560). I will swap out bug 1612538 into reserve.
|
|
Assignee | |
Comment 3•5 years ago
|
||
I cannot get the Puppeteer unit tests to correctly work with my additions for DOM.describeNode. So I will include this API and will push everything at once at the end.
|
|
Assignee | |
Comment 4•5 years ago
|
||
As discussed with Joel yesterday via Matrix, the object as returned is always a copy of the original object as referenced by the same nodeId/backgroundNodeId. As such we the method has to look for an existing DOM node in any of the known execution contexts, and create a new object inside the specified execution context.
That means DOM nodes are uniquely tracked across contexts, but objects will always be duplicated.
|
|
Assignee | |
Comment 5•5 years ago
|
||
Depends on D66937
|
|
Assignee | |
Comment 6•5 years ago
|
||
Depends on D68637
|
|
Assignee | |
Comment 7•5 years ago
|
||
Depends on D66937
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Comment 9•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/b87ac5f5e1d6
https://hg.mozilla.org/mozilla-central/rev/051cb91bd7aa
|
|
Assignee | |
Updated•5 years ago
|
|
||
Updated•4 years ago
|
Description
•