1687657 - Browser UI Freezes when opening the Browser Console

Status: RESOLVED FIXED

(DevTools :: Console, defect)

Description

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

Opening the Browser Console freezes Browser UI. It resumes when the Browser Console is closed.

STRs: (might be intermittent)

1. Switch on all Fission prefs.
2. Load http://janodvarko.cz/tests/fission/case10/index.html
3. Open the Browser Console (I am using Ctrl+Shift+J on Win)
4. The Browser is often frozen at this point, if not, try to open DevTools Toolbox (F12)

If feels like the browser UI (main) process would be halted at a breakpoint.

This might be a candidate for Fission M3 MVP.

Honza

Comment 1

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

Nicolas, can you reproduce this bug?
It's the one I've already been talking about, I am experiencing that quite often
Honza

Comment 2

[Julian Descottes [:jdescottes]]

Hi Honza,

Some additional questions:

• is this on a clean profile or on your regular nightly profile?
• do you have other tabs opened or only this one?
• what do you mean by "all fission prefs"? fission.autostart + devtools.testing.enableServerWatcherSupport + devtools.browsertoolbox.fission + devtools.target-switching.enabled? Anything else?

Testing on mac, I can't reproduce so far, the browser console opens quickly, nothing freezes.

Comment 3

[Alexandre Poirot [:ochameau]]

I'm wondering if bug 1682780 could have regressed something where we are hitting a debugger statement (or some sort of breakpoint) and pausing, without having the devtools frontend catching the "paused" event...

Comment 4

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

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

• what do you mean by "all fission prefs"? fission.autostart + devtools.testing.enableServerWatcherSupport + devtools.browsertoolbox.fission + devtools.target-switching.enabled? Anything else?

Those prefs yes.

I could reproduce the same issue today with a new fresh profile (just one tab opened)

New STRs:

1. Open Browser (no Browser Console)
2. Load http://janodvarko.cz/tests/fission/case10/index.html
3. Open DevTools, create an event BP for click
4. Click on the iframe, pause in debugger, resume
5. Open the Browser Console -> the Browser UI freezes

Perhaps just existence of the event BP might be a problem (not even needed to click)

Anyone can repro?

Honza

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

I can reproduce on OSX, here's my STR

1. Open data:text/html,<button>Click</button><script>document.querySelector("button").addEventListener("click", () => {document.body.append(document.createTextNode(Date.now()))})</script>
2. Open the debugger
3. Add a "click" event breakpoint
4. Click on the button in the content page
5. -> The debugger pauses, resume (from the debugger icon, not the overlay)
6. Open the browser console
7. On the browser try to open a new tab with the + button -> no tabs are added

Then if you close the Browser Console, the tab does open

if instead of trying to add a tab, I click a few tab on the button of the content page, I get errors in the terminal (those lines, repeated many times):

console.error: (new ReferenceError("SourceActor is not defined", "resource://devtools/server/actors/utils/sources-manager.js", 103))
JavaScript warning: resource://devtools/shared/ThreadSafeDevToolsUtils.js, line 82: debuggee 'resource://gre/modules/ConsoleAPIStorage.jsm:109' would run
DBG-SERVER threw an exception: ReferenceError: SourceActor is not defined
Stack: createSourceActor@resource://devtools/server/actors/utils/sources-manager.js:103:19
getScriptOffsetLocation@resource://devtools/server/actors/utils/sources-manager.js:239:12
getFrameLocation@resource://devtools/server/actors/utils/sources-manager.js:258:17
isFrameBlackBoxed@resource://devtools/server/actors/utils/sources-manager.js:279:40
_makeEventBreakpointEnterFrame/<@resource://devtools/server/actors/thread.js:815:31
CS_recordEvent@resource://gre/modules/ConsoleAPIStorage.jsm:109:63
reportException@resource://devtools/shared/ThreadSafeDevToolsUtils.js:82:13
reportDebuggerHookException@resource://devtools/server/actors/utils/make-debugger.js:93:57
CS_recordEvent@resource://gre/modules/ConsoleAPIStorage.jsm:109:63
reportException@resource://devtools/shared/ThreadSafeDevToolsUtils.js:82:13
reportDebuggerHookException@resource://devtools/server/actors/utils/make-debugger.js:93:57
CS_recordEvent@resource://gre/modules/ConsoleAPIStorage.jsm:109:63

not sure if this gives us much information about what's going on.

Comment 6

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

I can reproduce the issue using STRs from comment #5

Thanks Nicolas for testing this!

Honza

Comment 7

[Nicolas Chevobbe [:nchevobbe]]

I have a even simpler STR:

1. Go to data:text/html,
2. Open the debugger and set an event listener breakpoint for click events
3. Open the Browser Console
4. Try to open a new tab on the regular browser

Actual results: The tab isn't added

I added some logging, and I can see when doing step 4:

🍅 Pause
console.trace:
resource://devtools/server/actors/thread.js 876 _pauseAndRespond
resource://devtools/server/actors/thread.js 841 _pauseAndRespondEventBreakpoint
resource://devtools/server/actors/thread.js 822 _makeEventBreakpointEnterFrame/<
resource:///modules/BrowserUsageTelemetry.jsm 832 _addUsageListeners/<

so we're indeed pausing the wrong target

Comment 8

[Julian Descottes [:jdescottes]]

Can also reproduce with the STRs from comment 7.
I think I could also reproduce with comment 4, but the browser UI is not fully "frozen" at the end of the STRs. You can still scroll, interact a bit with devtools etc... The extra step of trying to open a tab really bricks the browser and makes it clear it is broken.

Comment 9

[Alexandre Poirot [:ochameau]]

This may have regressed from bug 1657310, so a while ago !

We break from the Browser Console's thread actor, because we initialize it from shared debugger data, shared between content and privileged toolboxes. But as we don't have any debugger panel in the Browser Console, we can't resume, nor see the breakpoint being hit. And as the browser console is in the main thread, it freezes because of its own breakpoint...

I'll look into that, as I'm used to work around this attach/options code.

Comment 10

[Alexandre Poirot [:ochameau]]

Regression confirmed.

Comment 11

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1687657 - [devtools] Avoid attaching the thread actor in the context of the browser console.

Thread actor's options are shared across all the toolboxes,
so that when you set any type of breakpoints, they will be passed to all the thread actor.
All the thread actor, of all the toolboxes.
So that when you set a breakpoint in the content toolbox,
they may be set in the browser toolbox and also in the browser console.

Here, we avoid doing anything around the thread actor when we are in the context
of the browser console, so that we avoid setting up any type of breakpoint.
They are set when calling ThreadActor.attach().

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/92251c943b32
[devtools] Avoid attaching the thread actor in the context of the browser console. r=nchevobbe

Comment 13

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

Thank you all for quick fix for this bug!

Note: The fix should be uplifted to beta when properly tested in Nightly.

Honza

Comment 14

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/92251c943b32