1225828 - getCachedMessages: TypeError: object in compartment marked as invisible to Debugger breaks console and other toolbox functionality completely

Status: RESOLVED FIXED

(DevTools :: Console, defect)

Description

[:Gijs (he/him)]

Sometimes, when working with the browser toolbox or browser console, I end up with:

error occurred while processing 'getCachedMessages: TypeError: object in compartment marked as invisible to Debugger
Stack: WCA_makeDebuggeeValue@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:435:21
WCA_prepareConsoleMessageForRemote/result.arguments<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:1545:20
WCA_prepareConsoleMessageForRemote@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:1544:24
WCA_onGetCachedMessages/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:739:27
WCA_onGetCachedMessages@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:738:11
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1605:15
DebuggerTransport.prototype._onJSONObjectReady/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:479:9
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/DevToolsUtils.js:87:14
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/DevToolsUtils.js:87:14
Line: 435, column: 21

in the console, after which any evaluation in the console is met with no reply, the debugger is broken, and so is the style editor if and only if I haven't opened it before running into this issue. The inspector seems to still work, though. I don't know why this happens, and I don't seem to be able to find general STR. It happens both on my mac and on my windows machine.

Does this error mean anything to people? Can we recover from it better somehow? Patrick, do you know and/or can you take a look, please?

Comment 1

[:Gijs (he/him)]

After some time the message is sometimes followed with:

timeout: Connection timeout. Check the Error Console on both ends for potential error messages. Reopen the Web Console to try again.

which never helps. It's also confusing that it says "Web Console" when I'm using the browser toolbox.

On nightly, the error in comment #0 is from: main.js:1474:0 which is inside https://dxr.mozilla.org/mozilla-central/source/devtools/server/main.js#1473

Comment 2

[Patrick Brosset <:pbro>]

Not sure who's looking after the console these days. Brian might know since he did some work with the console UI recently.

Comment 3

[Brian Grinstead [:bgrins]]

Do you have a particular STR to get this message?  We should be able to at least try/catch the call to makeDebugeeValue so that the console doesn't break, but I'd like to dig into it further to see what object is breaking things here.

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

This may be a separate use case, but I frequently see this error when using Browser Toolbox to debug tests with --jsdebugger.

The steps I performed then were:

1. Add "debugger;" somewhere in devtools/client/commandline/test/browser_cmd_screenshot.js
2. Run "mach mochitest devtools/client/commandline/test/browser_cmd_screenshot.js --jsdebugger"
3. Press button to start tests
4. When you hit the debugger line, check the console.  Error should already present, and console input is ignored.

Comment 5

[:Gijs (he/him)]

(In reply to Brian Grinstead [:bgrins] from comment #3)
> Do you have a particular STR to get this message?

Sadly, not really... especially not from a clean profile. I see this on my normal browser profiles, and now I'm seeing it on my windows nightly ("trunk") profile. Sometimes pretty quickly after startup. I'm fairly sure it requires at least opening the browser debugger, but I'm not 100% positive.

Can you describe what kind of circumstances would create objects like this? What kind of compartments are "invisible to the Debugger" when using the browser console (I would expect the browser debugger to be able to see everything)? Maybe that will help in trying to narrow down STR.

Comment 6

[Brian Grinstead [:bgrins]]

(In reply to :Gijs Kruitbosch from comment #5)
> (In reply to Brian Grinstead [:bgrins] from comment #3)
> > Do you have a particular STR to get this message?
> 
> Sadly, not really... especially not from a clean profile. I see this on my
> normal browser profiles, and now I'm seeing it on my windows nightly
> ("trunk") profile. Sometimes pretty quickly after startup. I'm fairly sure
> it requires at least opening the browser debugger, but I'm not 100% positive.
> 
> Can you describe what kind of circumstances would create objects like this?
> What kind of compartments are "invisible to the Debugger" when using the
> browser console (I would expect the browser debugger to be able to see
> everything)? Maybe that will help in trying to narrow down STR.

I don't know what would lead to this error message when using makeDebugeeValue.  Maybe Nick knows?

Comment 7

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

There are certain globals whose objects are used pervasively in the server and they must be made invisible to the debugger or else we get crazy bugs where the server tries to pause itself accidentally. The two big ones I can think of off the top of my head are (1) the global we use for importing Promise and (2) self-hosted JS functions (map, filter, etc) which are all in a single shared global.

Comment 8

[Brian Grinstead [:bgrins]]

Attachment: MozReview Request: Bug 1225828 - Avoid 'Object in compartment marked as invisible to Debugger' exceptions in the Browser Console / Browser Toolbox;r=fitzgen

Bug 1225828 - Avoid 'Object in compartment marked as invisible to Debugger' exceptions in the Browser Console / Browser Toolbox;r=jryans

Comment 9

[Brian Grinstead [:bgrins]]

I don't know how to add a test for this, any ideas?  I could reproduce as per Comment 4, and had to make a similar change to hasSafeGetter to be able to inspect the messages that are emitted in the test.

Comment 10

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Comment on attachment 8689232 [details]
MozReview Request: Bug 1225828 - Avoid 'Object in compartment marked as invisible to Debugger' exceptions in the Browser Console / Browser Toolbox;r=fitzgen

I don't know this area well enough, passing to :fitzgen.

Comment 11

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Comment on attachment 8689232 [details]
MozReview Request: Bug 1225828 - Avoid 'Object in compartment marked as invisible to Debugger' exceptions in the Browser Console / Browser Toolbox;r=fitzgen

(Don't know how to steal a review on reviewboard)

LGTM, you can test the method by creating a sandbox with invisibleToDebugger set and trying to inspect an object from that sandbox.

    const sandbox = new Cu.Sandbox(null, { invisibleToDebugger: true });
    const sandboxObj = sandbox.eval("new Object");
    WCA_makeDebuggeeValue(sandboxObj, sandbox);

Not 100% sure how to get at WCA_makeDebuggeeValue easily in a unit test, might be easier to do an integration test for that part or split it out from the console actor to somewhere easier to unit test.

Comment 12

[Brian Grinstead [:bgrins]]

Comment on attachment 8689232 [details]
MozReview Request: Bug 1225828 - Avoid 'Object in compartment marked as invisible to Debugger' exceptions in the Browser Console / Browser Toolbox;r=fitzgen

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/25579/diff/1-2/

Comment 13

[Brian Grinstead [:bgrins]]

(In reply to Nick Fitzgerald [:fitzgen][:nf] from comment #11)
> LGTM, you can test the method by creating a sandbox with invisibleToDebugger
> set and trying to inspect an object from that sandbox.
> 
>     const sandbox = new Cu.Sandbox(null, { invisibleToDebugger: true });
>     const sandboxObj = sandbox.eval("new Object");
>     WCA_makeDebuggeeValue(sandboxObj, sandbox);
> 
> Not 100% sure how to get at WCA_makeDebuggeeValue easily in a unit test,
> might be easier to do an integration test for that part or split it out from
> the console actor to somewhere easier to unit test.

Thanks, that was easy and I've confirmed it fails without patch / passes with it

Comment 14

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Comment on attachment 8689232 [details]
MozReview Request: Bug 1225828 - Avoid 'Object in compartment marked as invisible to Debugger' exceptions in the Browser Console / Browser Toolbox;r=fitzgen

https://reviewboard.mozilla.org/r/25579/#review23033

Thanks!

Comment 15

[Brian Grinstead [:bgrins]]

There's a lot of orange here but nothing seems related.. https://treeherder.mozilla.org/#/jobs?repo=try&revision=235483d74a68

Comment 16

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/ee24a6426247

Comment 17

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/ee24a6426247