1602748 - Experiment with target switching on reload and same-site navigation

Status: RESOLVED DUPLICATE of bug 1644397

(DevTools :: Framework, task, P3)

Description

[Julian Descottes [:jdescottes]]

One of the outcomes of the discussions around using JsWindowActors in DevTools (Bug 1565200) is that we want to rely on target switching in order to follow the lifecycle of JsWindowActors.

Short summary:

Pre-fission, DevTools targets are kept alive as long as possible. For instance when debugging a content page, the same BrowsingContextTarget will be used even if the user reloads or navigates etc... This is possible because reload and navigation do not trigger a process change, they to not invalidate the frame loader. So we just have to listen to those navigation events and let the panels know about them.

Post-fission, the DevTools parent process DebuggerServer will talk to the content process DebuggerServer via JsWindowActors. The lifecycle of those JsWindowActors is linked to the lifecycle of the global object (window object of the page). This means every time we reload and navigate, we are destroying and recreating the JsWindowActors.

We initially tried an implementation based on JsWindowActors that would be able to transparently handle reloads, as well as same-site navigations. But the implementation was quite fragile and complex. And also it didn't apply to different-site navigations. When navigating to a different site, the content process DebuggerServer has to be destroyed and recreated in the new process. Which means the Target actor also has to be destroyed and recreated, and consequently this triggers a top-level "target-switch".

So rather than keeping two implementations to handle similar issues, we decided to focus on the solution that could be used in all situations: target-switching. Instead of target-switching only when the process changes, we want to use target-switching every time the window global is destroyed.

Comment 1

[Alexandre Poirot [:ochameau]]

We probably want to look into that during M2, while not necessarily committing to doing it.

Comment 2

[Chris Peterson [:cpeterson]]

Tracking DevTools bugs for Fission Nightly (M6) milestone

Comment 3

[Julian Descottes [:jdescottes]]

See also https://phabricator.services.mozilla.com/D65521 from Bug 1593937

Comment 4

[Chris Peterson [:cpeterson]]

dt-fission-m2-reserve bugs do not need to block Fission Nightly (M6). For now, let's track them for Fission riding the trains to Beta (M7) so we revisit these bugs before we ship Fission.

Comment 5

[Neha Kochar [:neha]]

Bulk move of all dt-fission-m2-reserve bugs to Fission MVP milestone.

Comment 6

[Alexandre Poirot [:ochameau]]

Bug 1602748 is going to trigger this. Only once we navigate to another process, but that's already a good start.