Closed Bug 1720184 Opened 3 years ago Closed 3 years ago

browser toolbox's debugger is broken when using --jsdebugger against a mochitest

Categories

(DevTools :: Debugger, defect)

defect

Tracking

(firefox91 fixed, firefox92 fixed)

RESOLVED FIXED
92 Branch
Tracking Status
firefox91 --- fixed
firefox92 --- fixed

People

(Reporter: ochameau, Assigned: ochameau)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

./mach mochitest devtools/shared/commands/target/tests/browser_target_list_frames.js --jsdebugger
Fails with a debugger that stays blank because of the following exception:

resource://devtools/shared/protocol/types.js, line 548: Error: Can't find the actor ID for thread from root or target actor's form.
``
The debugger load flow throws right here:
https://searchfox.org/mozilla-central/rev/5227b2bd674d49c0eba365a709d3fb341534f361/devtools/client/debugger/src/main.js#97

await setPauseOnExceptions();

Because down the line, getAllFronts throws:
https://searchfox.org/mozilla-central/source/devtools/shared/commands/thread-configuration/thread-configuration-command.js#46-49
let threadFronts = await this._commands.targetCommand.getAllFronts(
  this._commands.targetCommand.ALL_TYPES,
  "thread"
);
It throws on still-attaching worker targets, which don't yet have `threadActor` set on their `targetForm`.
This is set asynchronously after being attached:
https://searchfox.org/mozilla-central/rev/5227b2bd674d49c0eba365a709d3fb341534f361/devtools/client/fronts/descriptors/worker.js#101

Worker targets only set threadActor late, quite asynchronously.
So that the target is registered in TargetCommand, but we can't call target.getFront
without having it to throw.

Assignee: nobody → poirot.alex
Status: NEW → ASSIGNED

I guess that's different enough from Bug 1707077

See Also: → 1707077
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7a1d15397ad9
[devtools] Fix browser toolbox against mochitests. r=jdescottes

Backed out for causing xpcshell failures on test_pause_exceptions-04.js.

Push with failures

Failure log

Backout link

Flags: needinfo?(poirot.alex)
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e359f6b67ca5
[devtools] Fix browser toolbox against mochitests. r=jdescottes
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch
Flags: needinfo?(poirot.alex)

Comment on attachment 9230806 [details]
Bug 1720184 - [devtools] Fix browser toolbox against mochitests.

Beta/Release Uplift Approval Request

  • User impact if declined: Browser toolbox wouldn't open sometimes (not clear exactly how frequent),
    but when using --jsdebugger command line argument started to permafail against mochitests. But given that browser toolbox tests started to permafail on beta (bug 1271813), this is probably always broken.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce: Run firefox with --jsdebugger command line argument. The toolbox will open but will eventually timeout and be broken as that can be seen on attachment 9230546 [details].
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Only impact DevTools, but not only the Browser Toolbox. This code is also used by regular DevTools.
    The patch is trivial and only prevents exception in case an unexpected state due to a race condition.
  • String changes made/needed:
Attachment #9230806 - Flags: approval-mozilla-beta?

Comment on attachment 9230806 [details]
Bug 1720184 - [devtools] Fix browser toolbox against mochitests.

Approved for 91 beta 6, thanks.

Attachment #9230806 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: