1712557 - Source code not available when pausing at a breakpoint

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P2)

Description

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

Following test case can be used to reproduce the problem. Debugger pauses, but there is no source code and stepping buttons are all disabled.

I have these prefs on:

• fission.autostart
• devtools.browsertoolbox.fission
• devtools.target-switching.server.enabled
• devtools.testing.enableServerWatcherSupport

STRs:

1. Load http://softwareishard.com/tests/fission/case1/index.html
2. Create BP in index.js (top level document), line 3
3. CLick this same page link on the page

AR:
The Debugger pauses, but there is no source code, there is also no way to resume it.

Sometimes I need to click the "this same page" link again on the loaded page to see the issue.

Also note that when I disable devtools.target-switching.server.enabled the problem is different. The page is not stack at loading anymore, but the BP never hits.

Honza

Comment 1

[Julian Descottes [:jdescottes]]

I managed to have a similar issue, but I need to follow more specific STRs. Most importantly, DevTools should not open on the Debugger on the initial page. If DevTools open on the Inspector and then you switch to the Debugger, I reproduce the bug. If I open DevTools on the Debugger directly, then no bug.

I had to click on the link twice. Then the page got stuck at load, but the Debugger was not "visibly" paused.
You say you had no way to resume the debugger, did it actually look paused?

Here are the logs I have when this happens:

console.error: "Failed to sendQuery in DevToolsWorkerParent" "DevToolsWorkerParent:instantiate-already-available" (new Error("DevToolsWorkerChild _watchWorkerTargets was called more than once for the same Watcher (Actor ID: \"server0.conn0.watcher2\")", "resource://devtools/server/connectors/js-window-actor/DevToolsWorkerChild.jsm", 214))
console.warn: "Failed to create DevTools Worker target for browsingContext" 29 "and watcher actor id" "server0.conn0.watcher2"
console.warn: (new Error("DevToolsWorkerChild _watchWorkerTargets was called more than once for the same Watcher (Actor ID: \"server0.conn0.watcher2\")", "resource://devtools/server/connectors/js-window-actor/DevToolsWorkerChild.jsm", 214))
JavaScript error: resource://devtools/client/debugger/src/utils/context.js, line 36: Error: Page has navigated
JavaScript error: resource://devtools/client/debugger/src/utils/context.js, line 36: Error: Page has navigated
JavaScript error: resource://devtools/client/debugger/src/utils/context.js, line 36: Error: Page has navigated

Comment 2

[Julian Descottes [:jdescottes]]

Honza: Retest and narrow the STRs (esp the prefs)

Comment 3

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

I've been testing this again, some more comments:

1. Note that clicking on the "this same page" link loads the same page from the different domain. There are only two domains (janodvarko.cz and softwareishard.cz) and the load alternates between the two. So, clicking on the link again (on the new page) loads the page from the previous domain.

Also note that breakpoints are tight to a domain, so that's why the BP in index.js hits every other time (if you create it just for one of the domains).

2. I didn't find more specific steps, looks like the issue is intermittent (steps in comment #0 are not always showing the problem)

3. When clicking on "Stop loading this page" (the refresh button) - to stop loading of a what seems to be a paused page, the paused overlay appears allowing to resume the page (the resume doesn't work though)

Comment 4

[Julian Descottes [:jdescottes]]

I also tried to reproduce while using various combinations of the prefs.

Fission OFF + server-side-target-switching OFF:
We break fine, no issue.

Fission ON + server-side-target-switching OFF:
We don't break because we miss the early breakpoint. I don't think we can reproduce this at all

Fission OFF + server-side-target-switching ON:
Stuck when loading the page

Fission ON + server-side-target-switching ON:
Stuck when loading the page (additionally, page looks blank, but I think it's just the intermediary about:blank step).

Summary: this breaks as soon as server-side-target-switching is enabled, fission or not. Blocking the enabling serverside target switching meta.

Comment 5

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1712557 - [devtools] Test hitting breakpoints via a reload link.

Comment 6

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1712557 - [devtools] Avoid emitting window-ready/window-destroyed for top level documents.

These events are redundant with target creation and destruction when the targets
follows the window lifecycle. These events are now only useful for in-process iframes.

Also, when the Target is instantiated by the server codebase, we end up registering
the code emitting these events sooner, so that we emit window-ready for the existing document!
On top of that, we end up also instantiating (and attaching) the thread actor earlier.
When combined, the thread actor was receiving window-ready for the existing top document
and was reseting itself after being attached and having registered the breakpoints.

Some followup would be required for will-navigate.
We get an initial will-navigate when the target instantiate, which can also confuse actors.
But as this event is important for DocumentEventWatcher, more work is needed to disable it.

Comment 7

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1712557 - [devtools] Ensure notifying about the target before start the resource watchers.

This is important to emit connectFromContent before processing the watched data.
We have to notify the parent process (and the client) about the new target actor.
And do that before any code in the content process tries to emit an event via this target acotr.
We will typically start the resources watchers when processing the watched data,
which will emit the resources-available-form on the target actor.

Writing a test for this is a bit tricky, as we start missing event when we get into it.
browser_resources_document_events.js starts failing without this patch because DOCUMENT_EVENT's dom-loading is emitted immediately
and is lost in the parent process.
I'm not sure we can write a better test than this existing failure.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3bab93803617
[devtools] Test hitting breakpoints via a reload link. r=bomsy
https://hg.mozilla.org/integration/autoland/rev/d7c5b966a457
[devtools] Avoid emitting window-ready/window-destroyed for top level documents. r=bomsy,jdescottes
https://hg.mozilla.org/integration/autoland/rev/853833eded4d
[devtools] Ensure notifying about the target before start the resource watchers. r=jdescottes

Comment 9

[Natalia Csoregi [:nataliaCs]]

Backed out for failures on browser_dbg-link-reload.js

backout: https://hg.mozilla.org/integration/autoland/rev/5dc29dc7ddef951ba60e01286d2f907ca12850c1

push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=853833eded4df81c45e4c6fb8b77063dcce3a1e2&selectedTaskRun=RCIM3__RTHS2jXan5jRwnA.0

failure log: https://treeherder.mozilla.org/logviewer?job_id=342296179&repo=autoland&lineNumber=6866

[task 2021-06-09T19:52:00.338Z] 19:52:00     INFO - TEST-PASS | devtools/client/debugger/test/mochitest/browser_dbg-link-reload.js | a new breakpoint was created - 
[task 2021-06-09T19:52:00.338Z] 19:52:00     INFO - Reload via a link, this causes special race condition different from F5
[task 2021-06-09T19:52:00.338Z] 19:52:00     INFO - Wait for paused
[task 2021-06-09T19:52:00.338Z] 19:52:00     INFO - 
[task 2021-06-09T19:52:00.339Z] 19:52:00     INFO - Waiting for state change: paused
[task 2021-06-09T19:52:00.339Z] 19:52:00     INFO - Console message: [JavaScript Warning: "Use of nsIFile in content process is deprecated." {file: "resource://gre/modules/NetUtil.jsm" line: 253}]
[task 2021-06-09T19:52:00.339Z] 19:52:00     INFO - Console message: [JavaScript Warning: "Use of nsIFile in content process is deprecated." {file: "resource://gre/modules/NetUtil.jsm" line: 253}]
[task 2021-06-09T19:52:00.340Z] 19:52:00     INFO - Buffered messages finished
[task 2021-06-09T19:52:00.340Z] 19:52:00     INFO - TEST-UNEXPECTED-FAIL | devtools/client/debugger/test/mochitest/browser_dbg-link-reload.js | Test timed out - 
[task 2021-06-09T19:52:00.425Z] 19:52:00     INFO - Removing tab.
[task 2021-06-09T19:52:00.425Z] 19:52:00     INFO - Waiting for event: 'TabClose' on [object XULElement].
[task 2021-06-09T19:52:00.435Z] 19:52:00     INFO - Got event: 'TabClose' on [object XULElement].
[task 2021-06-09T19:52:00.445Z] 19:52:00     INFO - Tab removed and finished closing
[task 2021-06-09T19:52:00.483Z] 19:52:00     INFO - TEST-PASS | devtools/client/debugger/test/mochitest/browser_dbg-link-reload.js | The main process DevToolsServer has no pending connection when the test ends -

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/241a24857721
[devtools] Test hitting breakpoints via a reload link. r=bomsy
https://hg.mozilla.org/integration/autoland/rev/be1d4d0af8ba
[devtools] Avoid emitting window-ready/window-destroyed for top level documents. r=bomsy,jdescottes
https://hg.mozilla.org/integration/autoland/rev/bc5ca21bf534
[devtools] Ensure notifying about the target before start the resource watchers. r=jdescottes

Comment 11

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/241a24857721
https://hg.mozilla.org/mozilla-central/rev/be1d4d0af8ba
https://hg.mozilla.org/mozilla-central/rev/bc5ca21bf534