Send one `browsingContext.contextDestroyed` event in case of removing a tree of iframes
Categories
(Remote Protocol :: WebDriver BiDi, task, P3)
Tracking
(Not tracked)
People
(Reporter: Sasha, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [webdriver:backlog])
The implementation of browsingContext.contextDestroyed event, which landed in the scope of bug1694390, in case of removing a tree of iframes we send the events for each removed iframe. But we would like to send only one event for the top iframe.
At the time of the initial implementation, the approach was when receiving the event to check if the parent or the top browsing context of the event target was discarded already, and if yes skip this event. But it didn't work for iframe tree, because the events would come first for an inner iframe and only then for the parent, so with this approach we couldn't know that the parent is going to be removed. To make it work, we might need some platform changes.
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Comment 1•2 years ago
|
||
Nika replied on Matrix:
As you've noticed we don't have a strict ordering for which order parent vs. child BCs are destroyed. You're probably observing two different orderings in this case because of process isolation. When in-process, we destroy the innermost first, then propagate outwards, but due to sending async messages in cross-process embedding situations, cross-process frames will appear to be discarded after the root ones. I don't believe we currently track the information you'd want to know (why the frame was destroyed) and pass it into any form of tracking for BC discarding unfortunately.
| Reporter | ||
Updated•2 years ago
|
Comment 2•1 year ago
|
||
Sasha, can you remember more details about the multiple vs single event? I just remembered this bug when reviewing https://github.com/web-platform-tests/wpt/pull/46562 but then I didn't see that there is a BiDi spec issue. So what did we actually agreed on?
Comment 3•1 year ago
|
||
Actually there is https://github.com/w3c/webdriver-bidi/pull/708 which this wpt PR originates from.
Updated•1 year ago
|
Description
•