Integrate "debug" button for SW with the new Debugger's thread panel
Categories
(DevTools :: Application Panel, enhancement, P1)
Tracking
(firefox73 fixed)
| Tracking | Status | |
|---|---|---|
| firefox73 | --- | fixed |
People
(Reporter: ladybenko, Assigned: ladybenko)
References
(Blocks 1 open bug)
Details
(Whiteboard: [m1.1-mvp])
Attachments
(2 files)
When we click the "Debug" button, we should switch to the debugger and make it automatically select the SW from the "threads" group.
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Comment 1•6 years ago
|
||
|
|
Assignee | |
Comment 2•6 years ago
|
||
|
|
Assignee | |
Updated•6 years ago
|
|
|
||
Comment 4•6 years ago
|
||
Backed out 2 changesets for causing a high devtools failure rate in browser_application_panel_debug-service-worker.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/e69c5e98543acbcd718697d92bba2c7a18e30f08
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=278801731&repo=autoland&lineNumber=979
[task 2019-11-29T16:45:31.561Z] 16:45:31 INFO - Buffered messages finished
[task 2019-11-29T16:45:31.561Z] 16:45:31 INFO - TEST-UNEXPECTED-FAIL | devtools/client/application/test/browser/browser_application_panel_debug-service-worker.js | A promise chain failed to handle a rejection: Protocol error (wrongState): Stack frames are only available while the debuggee is paused. - stack: paused/<@resource://devtools/client/debugger/src/actions/pause/paused.js:71:13
[task 2019-11-29T16:45:31.561Z] 16:45:31 INFO - asyncthunk/</</<@resource://devtools/client/debugger/src/actions/utils/middleware/thunk.js:29:45
[task 2019-11-29T16:45:31.561Z] 16:45:31 INFO - bindActionCreator/<@resource://devtools/client/shared/vendor/redux.js:644:12
[task 2019-11-29T16:45:31.561Z] 16:45:31 INFO - paused@resource://devtools/client/debugger/src/client/firefox/events.js:91:11
[task 2019-11-29T16:45:31.561Z] 16:45:31 INFO - asynccheckIfAlreadyPaused@resource://devtools/client/debugger/src/client/firefox/commands.js:428:28
[task 2019-11-29T16:45:31.561Z] 16:45:31 INFO - onConnect@resource://devtools/client/debugger/src/client/firefox.js:87:34
[task 2019-11-29T16:45:31.561Z] 16:45:31 INFO - asynconConnect@resource://devtools/client/debugger/src/client/index.js:82:28
[task 2019-11-29T16:45:31.561Z] 16:45:31 INFO - asyncbootstrap@resource://devtools/client/debugger/src/main.js:28:31
[task 2019-11-29T16:45:31.562Z] 16:45:31 INFO - open@resource://devtools/client/debugger/panel.js:45:38
[task 2019-11-29T16:45:31.562Z] 16:45:31 INFO - onLoad@resource://devtools/client/framework/toolbox.js:2449:27
[task 2019-11-29T16:45:31.562Z] 16:45:31 INFO - Rejection date: Fri Nov 29 2019 16:45:30 GMT+0000 (Greenwich Mean Time) - false == true - JS frame :: resource://testing-common/PromiseTestUtils.jsm :: assertNoUncaughtRejections :: line 265
[task 2019-11-29T16:45:31.562Z] 16:45:31 INFO - Stack trace:
[task 2019-11-29T16:45:31.562Z] 16:45:31 INFO - resource://testing-common/PromiseTestUtils.jsm:assertNoUncaughtRejections:265
[task 2019-11-29T16:45:31.562Z] 16:45:31 INFO - chrome://mochikit/content/browser-test.js:Tester_execTest/<:1100
[task 2019-11-29T16:45:31.563Z] 16:45:31 INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1104
[task 2019-11-29T16:45:31.563Z] 16:45:31 INFO - chrome://mochikit/content/browser-test.js:nextTest/<:932
[task 2019-11-29T16:45:31.563Z] 16:45:31 INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<:805
[task 2019-11-29T16:45:31.563Z] 16:45:31 INFO - Leaving test bound
|
|
||
Comment 5•6 years ago
|
||
Hi Julian, ladybenko is blocking ni at the moment, ni you for the above.
|
||
Comment 6•6 years ago
|
||
It seems to happen when the test clicks on the Debug button. For some reason the client gets a "paused" event, even though we shouldn't have any breakpoint at this stage?
Locally I can reproduce it. I could get the following stack trace on the client side that leads to the failing frames() call:
0:04.70 GECKO(12562) console.log: "Please file an issue: reasonType=" "attached"
0:04.70 GECKO(12562) getFrames@resource://devtools/shared/fronts/thread.js:71:17
0:04.70 GECKO(12562) getFrames@resource://devtools/client/debugger/src/client/firefox/commands.js:312:38
0:04.70 GECKO(12562) fetchFrames/<@resource://devtools/client/debugger/src/actions/pause/fetchFrames.js:19:33
0:04.70 GECKO(12562) thunk/</</<@resource://devtools/client/debugger/src/actions/utils/middleware/thunk.js:29:45
0:04.70 GECKO(12562) dispatch@resource://devtools/client/shared/vendor/redux.js:755:18
0:04.70 GECKO(12562) paused/<@resource://devtools/client/debugger/src/actions/pause/paused.js:51:11
0:04.70 GECKO(12562) thunk/</</<@resource://devtools/client/debugger/src/actions/utils/middleware/thunk.js:29:45
0:04.70 GECKO(12562) bindActionCreator/<@resource://devtools/client/shared/vendor/redux.js:644:12
0:04.70 GECKO(12562) paused@resource://devtools/client/debugger/src/client/firefox/events.js:91:11
0:04.70 GECKO(12562) async*checkIfAlreadyPaused@resource://devtools/client/debugger/src/client/firefox/commands.js:428:28
0:04.70 GECKO(12562) onConnect@resource://devtools/client/debugger/src/client/firefox.js:87:34
0:04.70 GECKO(12562) async*onConnect@resource://devtools/client/debugger/src/client/index.js:82:28
0:04.70 GECKO(12562) async*bootstrap@resource://devtools/client/debugger/src/main.js:28:31
0:04.70 GECKO(12562) open@resource://devtools/client/debugger/panel.js:45:38
0:04.70 GECKO(12562) onLoad@resource://devtools/client/framework/toolbox.js:2449:27
We can also see "Please file an issue: reasonType=" "attached" logged which seems to indicate we are pausing for an unexpected reason?
Beyond that there seem to be other exceptions as well.
It feels like this test is very similar to browser_dbg-windowless-service-workers.js which is already failing very often https://bugzilla.mozilla.org/show_bug.cgi?id=1594617 (with similar logs).
Brian, I see we started disabling browser_dbg-windowless-service-workers.js on some platforms. Do you have a suggestion to move forward here?
|
||
Comment 7•6 years ago
|
||
This is a different issue from the failure on windowless-service-workers.js (which is a missing null check, see bug 1594617). It is another debugger bug, though.
The paused event happens because whenever a target attaches to a thread, the thread initially enters a paused state (the "attached" reason type). The debugger has some code to detect initially paused threads (checkIfAlreadyPaused) and update the reducer for them, and some code to resume threads that have just been attached to (attachTargets). These operations are all asynchronous and this failure is an interleaving between them where we think a thread is paused and try to fetch its frames, but it ends up resuming first and throws an error on the frames request. This is all pretty complicated and I hope that the situation will improve when the debugger is no longer managing targets directly (bug 1572409).
In any case, the debugger ought to be able to deal with this interleaving. This fits into a class of problem in the debugger where we are performing an operation that has gone stale due to changes to the thread or navigation state. We have a mechanism already to deal with this, the ThreadContext object in debugger/src/utils/context.js, which is used to ignore reducer updates based on old thread/navigation configurations. Because the ThreadContext we got when paused will not be valid after resuming, even if we were able to get frames here we would not update the reducer with them. The best fix here is I think to ignore exceptions from the getFrames call if the thread context we are using is invalid. I've written this fix and will create a bug for it in a few minutes. It seems to be working on the test, though I did get a different failure at one point which looks like a problem with the registration front, pasted below.
devtools/client/application/test/browser/browser_application_panel_debug-service-worker.js
FAIL A promise chain failed to handle a rejection: this._frontCreationListeners is null - stack: manage@resource://devtools/shared/protocol/Front.js:105:5
read@resource://devtools/shared/protocol/types.js:346:21
_getServiceWorker@resource://devtools/shared/fronts/worker/service-worker-registration.js:63:43
get activeWorker@resource://devtools/shared/fronts/worker/service-worker-registration.js:47:17
listAllWorkers/<@resource://devtools/shared/fronts/root.js:122:65
listAllWorkers@resource://devtools/shared/fronts/root.js:121:19
async*getWorker@resource://devtools/shared/fronts/root.js:426:51
listWorkerTargets@resource://devtools/client/debugger/src/client/firefox/targets.js:90:60
async*updateTargets@resource://devtools/client/debugger/src/client/firefox/targets.js:144:25
fetchThreads@resource://devtools/client/debugger/src/client/firefox/commands.js:447:36
updateThreads/<@resource://devtools/client/debugger/src/actions/threads.js:25:34
thunk/</</<@resource://devtools/client/debugger/src/actions/utils/middleware/thunk.js:29:45
bindActionCreator/<@resource://devtools/client/shared/vendor/redux.js:644:12
threadListChanged@resource://devtools/client/debugger/src/client/firefox/events.js:119:11
setupEvents/<@resource://devtools/client/debugger/src/client/firefox/events.js:59:56
emit@resource://devtools/shared/event-emitter.js:190:24
emit@resource://devtools/shared/event-emitter.js:271:18
onPacket@resource://devtools/shared/protocol/Front.js:252:13
onPacket@resource://devtools/shared/client/debugger-client.js:506:13
send/<@resource://devtools/shared/transport/local-transport.js:70:25
exports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:111:22
DevToolsUtils.executeSoon*exports.executeSoon@resource://devtools/shared/DevToolsUtils.js:62:21
send@resource://devtools/shared/transport/local-transport.js:58:21
send@resource://devtools/server/debugger-server-connection.js:89:20
onWorkerListChanged@resource://devtools/server/actors/root.js:483:15
_notifyListChanged@resource://devtools/server/actors/worker/worker-target-actor-list.js:142:10
onUnregister@resource://devtools/server/actors/worker/worker-target-actor-list.js:158:12
|
|
||
Comment 8•6 years ago
|
||
Thanks for the detailed explanation! I must have misread the logs when looking at Bug 1594617, because indeed the failures are really different. While I was trying to fix this, I have seen this._frontCreationListeners is null as well. Seems like we are trying to get the activeWorker of an already destroyed service worker registration front.
If we fix the first issue you explained, it will be easier to fix this second one, happy to take a look!
|
||
Updated•6 years ago
|
|
|
Assignee | |
Comment 9•6 years ago
|
||
Thanks both of you for looking at this and the explanations!
I've rebased to get the fix that Brian applied, and can't seem to trigger the this._frontCreationListeners is null error, neither locally nor on Try. So I'm going to try to land again.
|
|
||
Comment 10•6 years ago
|
||
FWIW the frontCreationListeners error happens frequently now on browser_application_panel_list-domain-workers.js. I had to whitelist the error to land bug 1596939, see bug 1575427, but it should be a lot easier to reproduce / fix now.
|
||
Comment 11•6 years ago
|
||
|
|
||
Comment 12•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/a23e6cc88a9c
https://hg.mozilla.org/mozilla-central/rev/a402f30ccd36
Description
•