1707878 - Start creating server side targets for chrome / parent process documents

Status: RESOLVED FIXED

(DevTools :: Framework, enhancement)

Description

[Alexandre Poirot [:ochameau]]

The following code within the "watcher actor universe"
https://searchfox.org/mozilla-central/rev/6cbe34b441f7c7c29cd1e5f0e19c7000142f1423/devtools/server/actors/watcher/target-helpers/utils.js#32-37

  // Ignore globals running in the parent process for now as they won't be in a distinct process anyway.
  // And JSWindowActor will most likely only be created if we toggle includeChrome
  // on the JSWindowActor registration.
  if (windowGlobal.osPid == -1 && windowGlobal.isInProcess) {
    return false;
  }

Prevents the watcher actor from trying to create targets for document running in the parent process, typically about:robots. But it also prevent creating targets for all firefox UI documents like browser.xhtml, the browser console document, ...

We should relax this check a bit in order to allow creating targets for tabs loading document in the parent process, while still avoiding to create any target for all chrome document (browser.xhtml, browser console document, ...). We would only enable target for these document once we start creating targets for iframes running in the same process as their parent. These document are currently all debugged via the ParentProcessTargetActor.

Comment 1

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1707878 - [devtools] Allow chrome/parent process documents loaded in tabs.

Comment 2

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1707878 - [devtools] Ensure emitting top level target first when we start watching for targets.

This only failed with devtools.target-switching.server.enabled=true as we emit top level target
from the Watcher only when this is enabled.

This is covered by browser_target_list_frames.js asserting a precise order in targets.
This test was failing with the pref set to true and should now pass in all 4 configurations.
(fission on/off + server target on/off)

Also try to destroy the top level target last, after all the remote iframes ones, but I'm not sure it is as important.

Note that we were trying to add the top level BC multiple times between code in utils.js vs worker-helper and frame-helper:getWatchingBrowsingContexts.

Comment 3

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1707878 - [devtools] Test TargetCommand with a parent process pages.

Surprisingly, previous changeset fix this. Following changeset is rather there for cleanups.
The fact that we instantiate a first JSWindowActor pair from frame-helper seems to do the trick.
The new code in frame-helper no longer conditionaly create the target for the top BC.

I also silent an exception happening in this test without fission.

Comment 4

[Alexandre Poirot [:ochameau]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=38ed041b7e06bcf333e79a7934a73b749c5e5a39

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eaf62919de4d
[devtools] Ensure emitting top level target first when we start watching for targets. r=jdescottes,nchevobbe
https://hg.mozilla.org/integration/autoland/rev/0c161d2d1815
[devtools] Test TargetCommand with a parent process pages. r=jdescottes,nchevobbe
https://hg.mozilla.org/integration/autoland/rev/c718330e4497
[devtools] Allow chrome/parent process documents loaded in tabs. r=jdescottes,nchevobbe

Comment 6

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/eaf62919de4d
https://hg.mozilla.org/mozilla-central/rev/0c161d2d1815
https://hg.mozilla.org/mozilla-central/rev/c718330e4497