The Worker name should be reflected in the threads pane
Categories
(DevTools :: Debugger, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: jlast, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
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.
Reporter | ||
Comment 1•5 years ago
|
||
Comment 2•5 years ago
|
||
Ha, thanks for filing. I think I brought this up in slack many moons ago but didn't file an issue.
Comment 3•5 years ago
|
||
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.
Updated•5 years ago
|
Reporter | ||
Comment 4•5 years ago
|
||
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•4 years ago
|
||
Comment 6•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 7•4 years ago
|
||
Brian, can we review/land the attached patch?
Honza
Pushed by bhackett@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5af78a6c183e The Worker name should be reflected in the threads pane r=bhackett
Updated•4 years ago
|
Backout by nbeleuzu@mozilla.com: 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•4 years ago
|
||
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
Reporter | ||
Comment 11•4 years ago
|
||
I looked into this briefly and the test passed for me locally....
Comment 13•4 years ago
|
||
(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•4 years ago
|
||
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•4 years ago
|
||
Jason, is there anything we could do?
Honza
Comment 17•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Updated•2 years ago
|
Description
•