Use and update navigable seen node map when interacting with nodes of type Element and ShadowRoot
Categories
(Remote Protocol :: WebDriver BiDi, defect, P1)
Tracking
(firefox116 fixed)
| Tracking | Status | |
|---|---|---|
| firefox116 | --- | fixed |
People
(Reporter: whimboo, Assigned: whimboo)
References
(Blocks 3 open bugs)
Details
(Whiteboard: [webdriver:m7], [wptsync upstream][webdriver:relnote])
Attachments
(3 files, 2 obsolete files)
As per bug 1822466 I'm going to add a navigable seen nodes map to the parent process of Marionette. To allow inter-op tests between both protocols (eg. exchanging Element and ShadowRoot references) the same checks have to be done for WebDriver BiDi as well.
The feature of sending messages between the child and parent actors of the MessageHandler framework will be added on bug 1830404.
We should add it to M7.
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 1•2 years ago
|
||
Depends on D177492
| Assignee | ||
Comment 2•2 years ago
|
||
Depends on D177493
| Assignee | ||
Comment 3•2 years ago
|
||
Depends on D177494
| Assignee | ||
Comment 4•2 years ago
|
||
Depends on D177495
Updated•2 years ago
|
Comment 7•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/31607d74ee69
https://hg.mozilla.org/mozilla-central/rev/77f0334c7976
https://hg.mozilla.org/mozilla-central/rev/67d5d6a5f321
https://hg.mozilla.org/mozilla-central/rev/7f4052a38bc6
Comment 9•2 years ago
|
||
Backed out for causing regressions in the upstream wpt tests.
| Assignee | ||
Comment 12•2 years ago
|
||
After the backout we discussed possible solutions for BiDi which will prevent us from having to serialize and deserialize by async code. I've rewritten the code for two possible scenarios and created performance profiles (including this baseline profile) for each of them. None of them actually show a difference in performance which is good!
Try build:
https://treeherder.mozilla.org/jobs?repo=try&revision=0ae8d63a789739e75f99f5191b0d7939e3462100
- Passing the list of seenNodes through the full stack (profile) [2nd commit at the top]
While this would keep the serialize helper in the base module class synchronous we will have to pass the list of seen nodes through a lot of function calls. This is quite complex and error prone. Also it's unclear if this would work for the case of serializing window handles.
- Using a single IPC call after serialization to sync with the parent (profile) (top-most commit)
This alternative makes the shared serialize() helper async but only for the required IPC call. The general serialization of the underlying object is still sync and will block until it's completely done. So we should not face issues with modifications of the object while it's getting serialized.
Personally I'm actually in favor of the 2nd approach, which should also make it easier for us to handle windows in the future. But I would like to get some feedback first before continuing. Thanks.
Updated•2 years ago
|
| Assignee | ||
Comment 13•2 years ago
|
||
Depends on D177496
Comment 14•2 years ago
•
|
||
Thanks for the patches!
Before answering in details, I am having an issue with our current approach for the seenNodes map. We made this a parent process map per navigable, but I am no longer sure this is needed.
My assumptions:
- the seenNodes map in the parent process is only useful to check if an element is stale or not
- "stale" means either that the element is not connected or that it's document is not the "current" document
If that is correct, then for the parent process it doesn't matter if a given node id was seen for the navigable where we tried to find it or not. As long as it was seen "anywhere" it should result in a stale exception. Which means we should be able to make the seenNodes information in the parent process a simple set of ids?
I am probably overlooking something, so if someone can clarify the scenario or use cases where this doesn't hold, it would be helpful.
Edit: Henrik clarified that having it per navigable was important for cleaning up the map when navigables are destroyed, which makes sense as we don't want to indefinitely grow this map.
We can probably have another discussion at this point.
Comment 15•2 years ago
|
||
So considering that the browsing context id is needed to cleanup the list of seenNodes, I don't have a strong preference between the two approaches. The extra IPC call feels more complicated to me, but code wise and performance wise the two solutions seem relatively close, so if you think doing the extra IPC call will be helpful to support windows, it sounds fine.
(We also started discussing whether the browsing context id was actually needed when raising "no such element" exceptions even for BiDi. This depends whether the "seen" check can be global or if it should only be "was it seen in this navigable". And this is not completely clear to me. For classic in theory we throw a stale exception if the node's document is not the current document, so it feels like it should be global. But at the same time, since we clear the seenNodes map when a given navigable is destroyed, the "seen" check is never going to be really "global".)
Updated•2 years ago
|
| Assignee | ||
Comment 16•2 years ago
|
||
With the recent work on that stack of patches to include the browsing context I noticed that we actually use the wrong browsing context to store the generated shared id in the seenNodes list. In case of nodes to be returned from a different browsing context the id would get added to the wrong navigable, and as result trying to access the node (element, shadow root) will cause a no such element or no such shadow root failure.
I created https://github.com/w3c/webdriver-bidi/pull/445 to get this fixed.
Comment 17•2 years ago
|
||
I have basically the same opinion as Julian in terms of choosing the solution. The IPC call feels more complex, but I'm generally fine with it as well, especially if it should help to support windows.
| Assignee | ||
Comment 18•2 years ago
|
||
Also based on James' reply on the WIP directly I have abandoned it.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 19•2 years ago
|
||
Comment 20•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/183aa8c0f12e
https://hg.mozilla.org/mozilla-central/rev/3d43aa441eb2
https://hg.mozilla.org/mozilla-central/rev/6c51face7335
Updated•2 years ago
|
Description
•