Bugzilla

There is an interesting issue with the resource-watcher and top level target switching. I have mostly seen the issue with document event resources, which could arguably be replaced with targetDestroyed/Available once all targets are going through proper target switching. But it feels like the pattern could be an issue with any resource.

My scenario, I navigate from a parent process page to a content process page. 
The style editor is opened and watches for document event resources.

As soon as the content process page is created on the server, the target is created and we start watching for document events. 
We receive the target on the client side, but before we can notify the resource watcher, we have to attach the thread.

In the meantime, we emit the dom-loading, dom-interactive, dom-complete events. 
Since we are not yet listening for resources on this target on the client side, they end up in the resource cache of the targetFront ([searchfox](https://searchfox.org/mozilla-central/rev/358fbca0398ac651f5ea6030be39b1870ec180a5/devtools/client/fronts/targets/target-mixin.js#60-68)).

Then the thread attaches and we finally call the target-available callbacks, including [resourceWatcher onTargetAvailable](https://searchfox.org/mozilla-central/rev/358fbca0398ac651f5ea6030be39b1870ec180a5/devtools/shared/resources/resource-watcher.js#268).
Since this is a target-switching, we call `stopListening` for all resources.
Then we call `targetFront("resource-available-form",...)` ([searchfox](https://searchfox.org/mozilla-central/rev/358fbca0398ac651f5ea6030be39b1870ec180a5/devtools/shared/resources/resource-watcher.js#315-318)).
This will release our cached document-events. 
Finally we call `startListening` for all resources, including document events. This means we recreate the server-side listener. Since the document is already loaded, we will recreate the document events and emit them a second time.

There is an interesting issue with the resource-watcher and top level target switching. I have mostly seen the issue with document event resources, which could arguably be replaced with targetDestroyed/Available once all targets are going through proper target switching. But it feels like the pattern could be an issue with any resource.

My scenario, I navigate from a parent process page to a content process page. 
The style editor is opened and watches for document event resources.

As soon as the content process page is created on the server, the target is created and we start watching for document events. 
We receive the target on the client side, but before we can notify the resource watcher, we have to attach the thread.

In the meantime, we emit the dom-loading, dom-interactive, dom-complete events. 
Since we are not yet listening for resources on this target on the client side, they end up in the resource cache of the targetFront ([searchfox](https://searchfox.org/mozilla-central/rev/358fbca0398ac651f5ea6030be39b1870ec180a5/devtools/client/fronts/targets/target-mixin.js#60-68)).

Then the thread attaches and we finally call the target-available callbacks, including [resourceWatcher onTargetAvailable](https://searchfox.org/mozilla-central/rev/358fbca0398ac651f5ea6030be39b1870ec180a5/devtools/shared/resources/resource-watcher.js#268).
Since this is a target-switching, we call `stopListening` for all resources.
Then we call `targetFront.on("resource-available-form",...)` ([searchfox](https://searchfox.org/mozilla-central/rev/358fbca0398ac651f5ea6030be39b1870ec180a5/devtools/shared/resources/resource-watcher.js#315-318)).
This will release our cached document-events. 
Finally we call `startListening` for all resources, including document events. This means we recreate the server-side listener. Since the document is already loaded, we will recreate the document events and emit them a second time.