Closed Bug 1737865 Opened 3 years ago Closed 2 years ago

Firefox Nightly 95 can no longer connect to `mach test --jsdebugger xpcshell/...`

Categories

(DevTools :: Debugger, defect)

defect

Tracking

(firefox-esr91 wontfix, firefox93 wontfix, firefox94 wontfix, firefox95 wontfix, firefox96 fixed)

RESOLVED FIXED
96 Branch
Tracking Status
firefox-esr91 --- wontfix
firefox93 --- wontfix
firefox94 --- wontfix
firefox95 --- wontfix
firefox96 --- fixed

People

(Reporter: nalexander, Assigned: jdescottes)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

I can no longer connect to the xpcshell debug actor with Firefox Nightly 95. That is, I can no longer connect to localhost:6000 exposed by, for example

./mach test --jsdebugger toolkit/components/backgroundtasks/tests/xpcshell/test_backgroundtask_exitcodes.js

I can connect with Firefox Release 93.

I see errors like:

 0:38.50 pid:43398 console.error: "Error while calling actor 'root's method 'listAddons'" "This root actor has no browser addons."
 0:38.55 pid:43398 console.error: "Error while calling actor 'root's method 'listWorkers'" "This root actor has no workers."

but I don't know if these are the cause of the issue.

A regression window would be much appreciated, here. I just verified that I can connect with Firefox Beta 94.0b9, so this looks to be something in the Nightly 95 cycle.

QA Whiteboard: [qa-regression-triage]
Flags: needinfo?(jdescottes)

We probably only have the issue with devtools.browsertoolbox.fission set to true, which is only the case on Nightly.
So 94.0b9 might work just because it has the pref set to false.

Flags: needinfo?(jdescottes)

The error occurs when the toolbox tries to connect to the target:

console.error: "Exception while opening the toolbox" "Error: Protocol error (noServiceWorkerRegistrations): This root actor has no service worker registrations. from: root" (new Error("Protocol error (noServiceWorkerRegistrations): This root actor has no service worker registrations. from: root", "resource://devtools/shared/protocol/Front.js", 362))
onPacket/<@resource://devtools/shared/protocol/Front.js:362:31
DevTools RDP*request@resource://devtools/shared/protocol/Front.js:289:14
generateRequestMethods/</frontProto[name]@resource://devtools/shared/protocol/Front/FrontClassWithSpec.js:46:19
_updateRegistrations@resource://devtools/shared/commands/target/legacy-target-watchers/legacy-serviceworkers-watcher.js:212:30
_onRegistrationListChanged@resource://devtools/shared/commands/target/legacy-target-watchers/legacy-serviceworkers-watcher.js:173:16
listen@resource://devtools/shared/commands/target/legacy-target-watchers/legacy-serviceworkers-watcher.js:83:16
startListening@resource://devtools/shared/commands/target/target-command.js:397:47

This error occurs because xpcshell is treated as a "parent target" by target command. With devtools.browsertoolbox.fission set to true, we will try to listen to all targets, including service workers. This throws because we are missing the necessary actors on the server-side.

This was regressed by Bug 1714395, where we changed the logic used in target-command to compute the target types (switched from targetFront.isParentProcess to targetDescriptor.isParentProcessDescriptor).

  _computeTargetTypes() {
    let types = [];

    if (this.descriptorFront.isLocalTab) {
      types = [TargetCommand.TYPES.FRAME];
    } else if (this.descriptorFront.isParentProcessDescriptor) {
      const fissionBrowserToolboxEnabled = Services.prefs.getBoolPref(
        BROWSERTOOLBOX_FISSION_ENABLED
      );
      if (fissionBrowserToolboxEnabled) {
        types = TargetCommand.ALL_TYPES;
      }
    }
    // ...
  }
QA Whiteboard: [qa-regression-triage]
Flags: needinfo?(poirot.alex)
Flags: needinfo?(nchevobbe)
Regressed by: 1714395
Has Regression Range: --- → yes

Testing this in automation is not easy, but I suggest we add this to our devtools release tasks to avoid such issues being unnoticed for too long. This is broken since 91 cycle.

Assignee: nobody → jdescottes
Status: NEW → ASSIGNED

Set release status flags based on info from the regressing bug 1714395

(In reply to Julian Descottes [:jdescottes] from comment #4)

I suggest we add this to our devtools release tasks to avoid such issues being unnoticed for too long.

Ah yes, good idea! I'll update the doc and the template in the meta bug

Flags: needinfo?(nchevobbe)

thanks Nicolas! Clearing the ni for Alex since we are already working on a patch

Flags: needinfo?(poirot.alex)
See Also: → 1739115
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/710c7e460146
[devtools] Do not treat xpcshell targets as parent process targets r=ochameau,nchevobbe
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 96 Branch

The patch landed in nightly and beta is affected.
:jdescottes, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(jdescottes)

fwiw, this issue only happens when a certain preference is set to true, which is only the case by default on Nightly. So very little reason to uplift this.

Flags: needinfo?(jdescottes)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: