1603176 - Make the memory panel support target switching

Status: RESOLVED FIXED

(DevTools :: Memory, enhancement, P1)

Description

[Alexandre Poirot [:ochameau]]

Bug 1565263 landed the TargetList API which helps support switching to another target (as well as supporting the additional remote iframe target).
But we should followup in each tool in order to start using this new API.
The very first goal is to:

• stop memoizing the target/targetFront and may be also the target scoped front (inspector, console, thread, storage, ...). Instead we should use toolbox.targetList.targetFront in order to query for the current top level target front.
• support target switching by using TargetList.watchTargets. In a first iteration we would only care about the top level target. In order to do so, we can check for the isTopLevel argument being passed to the two callbacks register to watchTargets:

  this._toolbox.targetList.watchTargets([this._toolbox.targetList.TYPES.FRAME],
    ({ type, targetFront, isTopLevel }) => {
      if (isTopLevel) {
        // A new top level target is available
        // This will be fired on toolbox opening, for the first one,
        // And then, evertime we navigate to another process.
        // For now, you would need `devtools.target-switching.enabled` to be set to true
        // And navigate from any http website to about:robots, which loads into the parent process. Or enable Fission and navigate between two distinct top level domains.
      }
    },
    ({ type, targetFront, isTopLevel }) => {
      if (isTopLevel) {
        // A top level target has been destroyed
      }
    }

See bug 1565263 for how we migrated the console or bug 1578242 for the inspector.

Comment 1

[Alexandre Poirot [:ochameau]]

First, we can simplify the memory panel by removing target and gTarget as it looks like we aren't using them much:
https://searchfox.org/mozilla-central/rev/62a130ba0ac80f75175e4b65536290b52391f116/devtools/client/memory/panel.js#34,51-53

Then, we should use targetList.watchTargets in order to fetch a new memory front for each new top level target:
https://searchfox.org/mozilla-central/rev/62a130ba0ac80f75175e4b65536290b52391f116/devtools/client/memory/panel.js#35,38,40
And then communicate the new one to the initializer:
https://searchfox.org/mozilla-central/rev/62a130ba0ac80f75175e4b65536290b52391f116/devtools/client/memory/initializer.js#21-32
It isn't clear how to communicate the new memory front to the React Component, but we should...
So that all the callsite trying to do RDP request uses the new one:
https://searchfox.org/mozilla-central/search?q=front.&case=true&regexp=false&path=devtools%2Fclient%2Fmemory
An alternative would be to use dynamic getter(s) in the React Components so that it is easier to change it to a new one.

Comment 2

[Chris Peterson [:cpeterson]]

Tracking dt-fission-m2 bugs for Fission Nightly (M6)

Comment 3

[Julien Wajsberg [:julienw]]

It isn't clear how to communicate the new memory front to the React Component, but we should...

I think you can just rerender the app with the new values. React should do the right thing and triggers an update cycle because the classes are the same.

Comment 4

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1603176: Remove unused variable.

Comment 5

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1603176: Introduce updateMemoryFront action.

Depends on D61346

Comment 6

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1603176: Install target-switing mechanism.

Depends on D61347

Comment 7

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1603176: Add a test for target-switching on memory panel.

Depends on D61348

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7b47a4c77243
Remove unused variable. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/2485f2115890
Introduce updateMemoryFront action. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/635851b79924
Install target-switing mechanism. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/1d69574fa593
Add a test for target-switching on memory panel. r=jdescottes

Comment 9

[Razvan Maries]

Backed out for perma failures on browser_toolbox_tool_ready.js and browser_memory_fission_switch_target.js.

Push: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=success%2Cpending%2Crunning%2Ctestfailed%2Cbusted%2Cexception&searchStr=os%2Cx%2C10.14%2Cdebug%2Cmochitests%2Ctest-macosx1014-64%2Fdebug-mochitest-devtools-chrome-e10s-3%2Cm%28dt3%29&revision=1d69574fa593dce5cc506f76bf3727ab27a54de0

Logs: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=289688879&repo=autoland&lineNumber=7892
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=289688870&repo=autoland&lineNumber=21578

Backout: https://hg.mozilla.org/integration/autoland/rev/e6a92590e24435b270c96a471279375561dea0bb

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eb4b8d1dd951
Remove unused variable. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/cf0211316d05
Introduce updateMemoryFront action. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/7e27a418918f
Install target-switing mechanism. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/ae6a4fd79f67
Add a test for target-switching on memory panel. r=jdescottes

Comment 11

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/eb4b8d1dd951
https://hg.mozilla.org/mozilla-central/rev/cf0211316d05
https://hg.mozilla.org/mozilla-central/rev/7e27a418918f
https://hg.mozilla.org/mozilla-central/rev/ae6a4fd79f67