Bugzilla

I think the issue is that we emit will-navigate as a parent process resource, from the watcher. 

We trust resource-command to find which "target" this will-navigate corresponds to based on the browsingContextId in the resource.
However, in "parent-process" mode, we don't have a target created for individual window globals, so we fallback on the only available target: the parent process one.

In the long run I think this would be addressed by switching back to targetAvailable instead of will-navigate.

I think the issue is that we emit will-navigate as a parent process resource, from the watcher. 

We trust resource-command to find which "target" this will-navigate corresponds to based on the browsingContextId in the resource.
However, in "parent-process" mode, we don't have a target created for individual window globals, so we fallback on the only available target: the parent process one.

In the long run I think this would be addressed by switching back to targetAvailable instead of will-navigate.

Edit: Specifically, we are retrieving the wrong target at https://searchfox.org/mozilla-central/rev/b19830c6b22f73758862d34d2c64f57735890e90/devtools/client/fronts/watcher.js#159-167. This fallback mechanism might not make sense with EFT enabled? With EFT, if we can't get a target for a given browsing context id, it means it is out of scope. But maybe here we should rather fix the server to avoid emitting will-navigate at all in this configuration