1589908 - The Worker name should be reflected in the threads pane

Status: RESOLVED FIXED

(DevTools :: Debugger, enhancement, P3)

Description

[Jason Laster [:jlast]]

It'd be great if the threads pane took advantage of the worker's name field when determining the name to show.

Aside from DevTools, the name is also accessible from within the Worker itself via global name (or http://self.name), which can help with logging or identifying which thread ID you're in.

https://twitter.com/RReverser/status/1185680151780233219

Comment 1

[Jason Laster [:jlast]]

Attachment: EHRhz8eXkAARZTS.png

Comment 2

[:Harald Kirschner :digitarald]

Ha, thanks for filing. I think I brought this up in slack many moons ago but didn't file an issue.

Comment 3

[Bryan Kok [:transfusion]]

Hi, I'd love to work on this bug but I'd like some pointers -
First I looked at how the worker thread being rendered in the <Thread/> secondary pane was represented in the redux store and I found the threads reducer.
I searched for functions that would dispatch an action with type INSERT_THREADS and I found fetchThreads.
It seems like fetchThreads returns a list of Thread plain objects created by createThread. I was thinking that here is the place where I would check whether the thread is a worker and set the name accordingly.
The second argument to createThread however is of type WorkerTargetFront. Turns out the current name is the last path of the URL, which in the case of a web worker constructed from a blob would be its UUID.
I don't yet understand how to use WorkerTargetFront and this is my first time delving into actors/fronts. I was wondering whether it's possible to call self.name on the DedicatedWorkerGlobalScope of the worker in the same manner as the toolbox spawned by about:debugging#workers does.

Comment 4

[Jason Laster [:jlast]]

Thanks Bryan for looking into this. I think you're on the right path.

I'd start by looking in the worker actor
https://searchfox.org/mozilla-central/source/devtools/server/actors/targets/worker.js#45-71

which has access to the underlying worker

and then see if you can pass down the name field in the form.

once the worker front has the name, it will be a lot easier to decide what to do

Worker --> Worker Actor --> Worker Front --> redux store --> threads pane --> worker component

Comment 5

[Bryan Kok [:transfusion]]

Attachment: Bug 1589908 - The Worker name should be reflected in the threads pane r=jlast

Comment 6

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

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:transfusion, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 7

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Brian, can we review/land the attached patch?

Honza

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5af78a6c183e
The Worker name should be reflected in the threads pane r=bhackett

Comment 9

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/28f9b839e540
Backed out changeset 5af78a6c183e for dt failures on browser_dbg-toolbox-workers.js . CLOSED TREE

Comment 10

[Narcis Beleuzu [:NarcisB]]

Backed out for dt failures on browser_dbg-toolbox-workers.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/28f9b839e5406a3c0f4e9accd32f5ce5d327b45a
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=282153400&repo=autoland&lineNumber=21981

Comment 11

[Jason Laster [:jlast]]

I looked into this briefly and the test passed for me locally....

Comment 12

[Jason Laster [:jlast]]

Could you look into this?

Comment 13

[Brian Hackett [Laid off!]]

(In reply to Jason Laster [:jlast] from comment #12)

Could you look into this?

The problem here is that the evaluateJS call is returning {"type":"undefined"} object, which gets coerced to an [object Object] string that is shown in the debugger and breaking the test (which looks for specific worker names). I don't know why this only fails in some cases. The best fix here is probably to only use the evaluateJS result if it is a string.

Comment 14

[Patrick Brosset <:pbro>]

Hey Jason, do you mind taking another look at the phabricator revision please? It looks like work was done after the initial review and backout and it seems like a final review is needed in order to land again.

Comment 15

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Jason, is there anything we could do?

Honza

Comment 16

[Jason Laster [:jlast]]

Thanks, added it to my queue

Comment 17

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

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 18

[kolAflash]

It's still an issue in Firefox Nightly 133.0a1 (2024-10-04).

This makes debugging really annoying. If you spawn several workers from the same Javascript file you just don't know which worker to pick in the Firefox debugger. So you've got to try though all of them.

Chromium shows the workers name instead of the Javascript filename. And Chromium even sticks to that worker when you reload the page. So Chromium switches back to the worker with the same name, as soon as it appears after the reload. Really convenient!

Comment 19

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 20

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1589908 - [devtools] Expose Worker name via nsIWorkerDebugger.name.

Comment 21

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1589908 - [devtools] Display worker custom name instead of URL in DevTools.

This patch affects both the console context selector and debugger source tree / thread panels.
The URL should still be displayed in tooltips.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b272f8689188
[devtools] Expose Worker name via nsIWorkerDebugger.name. r=dom-worker-reviewers,asuth
https://hg.mozilla.org/integration/autoland/rev/4243ea261413
[devtools] Display worker custom name instead of URL in DevTools. r=devtools-reviewers,nchevobbe

Comment 23

[amarc]

https://hg.mozilla.org/mozilla-central/rev/b272f8689188
https://hg.mozilla.org/mozilla-central/rev/4243ea261413