Closed Bug 1532238 Opened 6 years ago Closed 6 years ago

Autocomplete does not work in browser console

Categories

(DevTools :: Console, defect, P1)

defect

Tracking

(firefox67 fixed)

RESOLVED FIXED
Firefox 67
Tracking Status
firefox67 --- fixed

People

(Reporter: nchevobbe, Assigned: ochameau)

References

(Blocks 1 open bug)

Details

(Whiteboard: [qa-67b-p2])

Attachments

(1 file, 1 obsolete file)

When typing in the browser console input, there's the following error:

error occurred while processing 'autocomplete: TypeError: debugger and debuggee must be in different compartments
Stack: autocomplete@resource://devtools/server/actors/webconsole.js:1185:30
onPacket@resource://devtools/server/main.js:1291:58
send/<@resource://devtools/shared/transport/local-transport.js:64:23
exports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:109:22
exports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:109:22
Line: 1185, column: 30 main.js:1160
    _unknownError resource://devtools/server/main.js:1160
    onPacket resource://devtools/server/main.js:1294
    send resource://devtools/shared/transport/local-transport.js:64
    makeInfallible resource://devtools/shared/ThreadSafeDevToolsUtils.js:109
    makeInfallible resource://devtools/shared/ThreadSafeDevToolsUtils.js:109

This is the offender devtools/server/actors/webconsole.js#1185 (basically, when we try to add a debuggee)

This is related to bug 1515290.

Now that we share a unique compartment between all chrome contexts (devtools sandboxes, jsm, chrome documents, js xpcom, ...),
we now have to flag the loader with invisibleToDebugger=true when we are debugging a chrome context (one of which I listed here).
This is only for the server. This is only to ensure that the actors, which use the Debugger API are loaded in a distinct compartment. invisibleToDebugger ends up forcing loading all the modules in a special, distinct compartment. This compartment story is specific to Debugger API, the debugger has to know the boundaries of its debuggee and it uses compartments boundaries to know if a given frame is part of the debuggee or the debugger implementation.

So, for the browser console, we are debugging such chrome context. We have to ensure that the DebuggerServer used by the browser console is loaded by a Loader with invisibleToDebugger=true. I most likely missed that when working on bug 1515290.

Blocks: 1517210
Assignee: nobody → poirot.alex

Bug 1517210 ensured that the debugger server was running in the shared system compartment.
The same one for JSMs, JS-XPCOM and DevTools Sandboxes. But that doesn't work when
the server has to debug system Javascripts. In such case, we have to ensure loading
the server in a special loader flagged with invisibleToDebugger=true. This forces
loading the server in another compartment and helps the debugger indentify the boundaries
between debugee and debugger code.

Attached file Bug 1532238 - Add test. (obsolete) —

Depends on D22062

Attachment #9048424 - Attachment is obsolete: true
Blocks: 1532653

I'm having a hard time having a green test on try for this, so I'll move the test to followup bug 1532653.

Here is a new try:
https://treeherder.mozilla.org/#/jobs?repo=try&searchStr=dt4&revision=c76e5b0e426c6f2cb5705044a3ff0606d9647aba

Pushed by apoirot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fccf1be20f4b Run Browser console's server in a dedicated compartment. r=nchevobbe
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
Whiteboard: [qa-67b-p2]
Regressions: 1544329
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: