1890759 - Error "Services.prefs is undefined" when connecting to a worker target

Status: RESOLVED FIXED

(DevTools :: Debugger, defect)

Description

[Julian Descottes [:jdescottes]]

The file devtools/server/actors/utils/event-breakpoints.js is unconditionally using Services.prefs.getBoolPref at https://searchfox.org/mozilla-central/rev/1f27a4022f9f1269d897526c1c892a57743e650c/devtools/server/actors/utils/event-breakpoints.js#134 but throws with Services.prefs is undefined. I imagine Services.prefs is unavailable in workers?

This probably means event breakpoints are broken for worker targets at the moment.

Note that another condition from the same file breaks on load "InvokeEvent" in win because win is also undefined in worker context.
Edit: I am not sure which event breakpoints are actually supported for worker targets however.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

:nchevobbe, since you are the author of the regressor, bug 1867326, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Nicolas Chevobbe [:nchevobbe]]

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

The file devtools/server/actors/utils/event-breakpoints.js is unconditionally using Services.prefs.getBoolPref at https://searchfox.org/mozilla-central/rev/1f27a4022f9f1269d897526c1c892a57743e650c/devtools/server/actors/utils/event-breakpoints.js#134 but throws with Services.prefs is undefined. I imagine Services.prefs is unavailable in workers?

I can't reproduce on a page with workers. Do you remember where you saw that in Julian?

This probably means event breakpoints are broken for worker targets at the moment.
Note that another condition from the same file breaks on load "InvokeEvent" in win because win is also undefined in worker context.
Edit: I am not sure which event breakpoints are actually supported for worker targets however.

We do support some events, like "Script First Statement", which is fired when the worker is created. For example, on https://nchevobbe.github.io/demo/console-test-app.html , if I click the "Spawn worker" button, the debugger does pause on the created worker's first line

Comment 3

[Julian Descottes [:jdescottes]]

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #2)

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

The file devtools/server/actors/utils/event-breakpoints.js is unconditionally using Services.prefs.getBoolPref at https://searchfox.org/mozilla-central/rev/1f27a4022f9f1269d897526c1c892a57743e650c/devtools/server/actors/utils/event-breakpoints.js#134 but throws with Services.prefs is undefined. I imagine Services.prefs is unavailable in workers?

I can't reproduce on a page with workers. Do you remember where you saw that in Julian?

Sorry I should have clarified: this happens only when you try to debug a worker target (so with a dedicated worker toolbox started from about:debugging). It's interesting that it doesn't happen at all for a toolbox debugging a worker in a webpage. In both cases we seem to create a worker target and to load the utils/event-breakpoints.js in the worker loader.

But when we are debugging a webpage, we never seem to call the condition methods for the event breakpoints from the worker loader.
I think it's because we only call getEventListenerBreakpointTypes for toplevel targets (here). So it's only sent to the thread actor of the worker target in the special case where the worker target is also the top level target.

STRs:

• open https://mdn.github.io/dom-examples/web-workers/fibonacci-worker/
• open about:debugging > This Nightly
• inspect fibonacci.js under "Other Workers"

You should have the error mentioned in the stderr/stdout of the browser.

Comment 4

[Julian Descottes [:jdescottes]]

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #2)

We do support some events, like "Script First Statement", which is fired when the worker is created. For example, on https://nchevobbe.github.io/demo/console-test-app.html , if I click the "Spawn worker" button, the debugger does pause on the created worker's first line

I see, so in the special case of a worker toolbox, this is probably not relevant because spawning the worker would require a new dedicated toolbox. For service workers it seems we support also XHR/fetch event breakpoints, but even though the condition throws it still seems to work. So overall I think this has very low impact on users, it's mostly log pollution / correctness.

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

Thanks for the information Julian.
I'm not even able to have a worker toolbox with my regular profile, this is failing with front.listWorkers is not a function" (new TypeError("front.listWorkers is not a function", "resource://devtools/shared/commands/target/legacy-target-watchers/legacy-workers-watcher.js", 81))
But running firefox with a fresh profile, I can see the issue indeed

Comment 6

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1890759 - [devtools] Fix event-breakpoint.js errors in worker toolbox. r=#devtools-reviewers.

• Guard Services.prefs as this isn't available in workers
• Pass worker's global to getAvailableEventBreakpoints when in worker toolbox
• Check that global exists before checking property on it

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5d0cc46227fd
[devtools] Fix event-breakpoint.js errors in worker toolbox. r=devtools-reviewers,jdescottes.

Comment 8

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/5d0cc46227fd

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:nchevobbe, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox125 to wontfix.

For more information, please visit BugBot documentation.

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

it was a bit too late for uplift