Convert devtools tests debugging chrome context and interacting with server references.

RESOLVED FIXED in Firefox 66

Status

enhancement
P1
normal
RESOLVED FIXED
4 months ago
4 months ago

People

(Reporter: ochameau, Assigned: ochameau)

Tracking

(Blocks 1 bug)

unspecified
Firefox 66
Dependency tree / graph

Firefox Tracking Flags

(firefox66 fixed)

Details

Attachments

(4 attachments)

Assignee

Description

4 months ago

Bug 1515290 is going to make debugging chrome contexts special.
When attaching to a chrome context, the DebuggerServer used to create actors is going to be loaded in a distinct loader, flagged with invisibleToDebugger=true. That's to load the actors and especially the Debugger API is a distinct compartment. This is a prerequisite to be able to debug chrome, otherwise the debugger and the debuggee would be in the same compartment.

Unfortunately, such change is going to break any test that is attaching to a chrome/system principal context (chrome:// page, main process, ...) AND trying to access the actors/DebuggerServer from the test script. Accessing the DebuggerServer is going to be more complex as it will be loaded in a distinct loader which won't be easy to have access to.

Most of the tests doing these two things are mochitest-chrome. They are not testing against chrome/privileged document on purpose, it is only historical. These tests just happened to be written originally as mochitest chrome and have never been refactored to use browser mochitest like most of our tests.

Re-unfortunately, converting them to browser mochitest isn't really trivial as they are very old and often use callbacks and assume having direct access to server parts. Whereas the client and actors, in a more common setup where you are debugging a tab running in content, are running in two distinct processes. So a big part of the work here is to go through ContentTask.spawn to reach the server bits. The rest is about using async/await and existing browser mochitest helpers.

Fortunately, this work improves a lot the readability of these tests!!

Assignee

Updated

4 months ago
Assignee: nobody → poirot.alex
Assignee

Updated

4 months ago
Priority: -- → P1
Assignee

Comment 2

4 months ago
These tests were using chrome URL for no good reason.
With the current bug, the pages running in system principal will be debugged with a special setup.
Actors will be run with modules loaded in a distinct loader in order to be executed
in a distinct compartment, distinct from the shared system principal compartment.
That a prerequisite for the Debugger API. It has to run in a distinct compartment than its debuggee.
It makes it harder to reach the actual DebuggerServer being used and register actors.
So it is easier to switch to a unprivileged test document loaded in the content process.
Assignee

Comment 3

4 months ago
This test was using chrome mochitest which forces the test page to be running in chrome and in parent process.
This doesn't reflect typical setup where the page runs unprivileged in content process.
Also, with the current bug, the pages running in system principal will be debugged with a special setup.
Actors will be run with modules loaded in a distinct loader in order to be executed
in a distinct compartment, distinct from the shared system principal compartment.
That a prerequisite for the Debugger API. It has to run in a distinct compartment than its debuggee.

Depends on D16824
Assignee

Comment 4

4 months ago
These tests were using chrome mochitest which forces the test page to be running in chrome and in parent process.
This doesn't reflect typical setup where the page runs unprivileged in content process.
Also, with the current bug, the pages running in system principal will be debugged with a special setup.
Actors will be run with modules loaded in a distinct loader in order to be executed
in a distinct compartment, distinct from the shared system principal compartment.
That a prerequisite for the Debugger API. It has to run in a distinct compartment than its debuggee.

Depends on D16825
Assignee

Comment 5

4 months ago
These two tests were using chrome mochitest which forces the test page to be running in chrome and in parent process.
This doesn't reflect typical setup where the page runs unprivileged in content process.
Also, with the current bug, the pages running in system principal will be debugged with a special setup.
Actors will be run with modules loaded in a distinct loader in order to be executed
in a distinct compartment, distinct from the shared system principal compartment.
That a prerequisite for the Debugger API. It has to run in a distinct compartment than its debuggee.

Depends on D16826

Comment 7

4 months ago
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0b8dbea06354
Convert server tests using chrome documents to use content one. r=yulia
https://hg.mozilla.org/integration/autoland/rev/552b8ad866be
Convert memory tests using chrome documents and using server references directly to browser mochitests. r=julienw
https://hg.mozilla.org/integration/autoland/rev/9bbfd13f52fa
Convert inspector tests using chrome documents and using server references directly to browser mochitests. r=pbro
https://hg.mozilla.org/integration/autoland/rev/f8a0a0a3cce8
Convert console tests using chrome documents and using server references directly to browser mochitests. r=nchevobbe
You need to log in before you can comment on or make changes to this bug.