Convert devtools tests debugging chrome context and interacting with server references.
Categories
(DevTools :: Framework, enhancement, P1)
Tracking
(firefox66 fixed)
| Tracking | Status | |
|---|---|---|
| firefox66 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
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•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 1•5 years ago
|
||
|
|
Assignee | |
Comment 2•5 years 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•5 years 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•5 years 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•5 years 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
|
|
Assignee | |
Comment 6•5 years 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
|
||
Comment 8•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/0b8dbea06354
https://hg.mozilla.org/mozilla-central/rev/552b8ad866be
https://hg.mozilla.org/mozilla-central/rev/9bbfd13f52fa
https://hg.mozilla.org/mozilla-central/rev/f8a0a0a3cce8
Description
•