Bugzilla

I'm wondering if this depends on bug 1602748, where we would spawn one target per WindowGlobal.

Here for the iframe picker, we need to spawn targets for in-process iframe. Today, they are being debugged via the top level target.
But it would be nice if all iframes were debugged the same way, via a dedicated target.
But doing this means that all features currently broken for remote iframe, will suddently also be broken for in-process iframes.

Otherwise, it means that the iframe picker has to handle both codepath, which may be very hairy:
* in-process iframes, with existing code, listening to `frameUpdate` event on top level target, and using `BrowsingContextTargetActor.switchToTarget`, in order to do a server side "document switching",
* remote iframes, with new code to write, listening to target available, and doing a target switching on the client side, via `TargetList.switchToTarget`.

I'm wondering if this depends on bug 1602748, where we would spawn one target per WindowGlobal.

Here for the iframe picker, we need to spawn targets for in-process iframe. Today, they are being debugged via the top level target.
But it would be nice if all iframes were debugged the same way, via a dedicated target.
But doing this means that all features currently broken for remote iframe, will suddently also be broken for in-process iframes.

Otherwise, it means that the iframe picker has to handle both codepath, which may be very hairy:
* in-process iframes, with existing code, listening to `frameUpdate` event on top level target, and using `BrowsingContextTargetActor.switchToFrame`, in order to do a server side "document switching",
* remote iframes, with new code to write, listening to target available, and doing a target switching on the client side, via `TargetList.switchToTarget`.