As noticed while working on bug 1636373 we send out Runtime.executionContextDestroyed events for all the frames when leaving a page triggered by a navigation. When using Chrome I don't see such an event at all, but only a single Runtime.executionContextsCleared event.

We should figure out when we have to send the destroyed events, and if we should do at all under such a situation. Maybe it's not done because all contexts are removed and it wouldn't make sense to send individual destroy events.

Right now nothing seems to be broken based on our current behavior.

Runtime.executionContextsCleared is per-target/session in Chrome.

I think it means that all executionContects, default or not, were destroyed in the inspected target.

Sorry for the double message, I thought it'd be better to add more info based on my research:

The event in Chrome does not reference any frame or specific execution context; consequently, it is meant to be a per-session event.

Additionally, if there are multiple execution targets assigned to a particular top level frame, it is still fired only once.

For example when the top level frame (the target) is closed or navigated to some other page, this event is fired and no other executionContextDestroyed seems to be fired. This happens only with the top level frame. In all other cases, navigating to some page, reloading it, or removing a frame/iframe from a page, the executionContextDestroyed event is fired for that particular execution context.

Maybe it's not done because all contexts are removed and it wouldn't make sense to send individual destroy events.

So yes, I believe this is the reason this event is fired this way.

Hope this helps.

For example when the top level frame (the target) is closed or navigated to some other page, this event is fired and no other executionContextDestroyed seems to be fired.

That's incorrect/poorly explained. executionContextDestroyed is still fired for sub frames, but on the main frame only executionContextsCleared is fired. Sorry for that.

Something else happens when executionContextsCleared is fired and I think that's what the event is meant to signify: the executionContextCreated events fired after executionContextsCleared have their IDs restarting from 1.