Load DAMP's root module using a DevTools browser-loader
Categories
(DevTools :: Framework, task, P3)
Tracking
(firefox86 fixed)
| Tracking | Status | |
|---|---|---|
| firefox86 | --- | fixed |
People
(Reporter: jdescottes, Assigned: jdescottes)
References
Details
Attachments
(5 files, 2 obsolete files)
Module paths in DAMP are dyamically generated.
Normally to get the path to a module, you need to rely on the rootURI of the extension. Eg rootURI.resolve("content/tests/some/test/path"). We use that in a few spots in DAMP and we also use relative paths our require calls to avoid using it too much.
However we migrated all DevTools code to use absolute require calls and we could leverage the DevTools loader to do the same here.
| Assignee | ||
Comment 1•5 years ago
|
||
Depends on D97626
Using the BrowserLoader still allows DAMP.js to use the window globals, but makes it so that require is immediately available.
| Assignee | ||
Comment 2•5 years ago
|
||
Depends on D97727
The root DAMP path is dynamic, so we need to expose a new configuration option on the browser loader to add a damp-test root path
| Assignee | ||
Comment 3•5 years ago
|
||
Depends on D97728
Similar to what was done for the devtools/ folder, we should use absolute paths in all our require calls.
| Assignee | ||
Comment 4•5 years ago
|
||
Depends on D97729
rootURI is still necessary to register the JSWindowActors used to monitor load events.
Exposing it directly on the window object avoid having to pass it as an argument and will allow to further refactor the damp.js module.
| Assignee | ||
Comment 5•5 years ago
|
||
Depends on D97730
Remove some leftover ChromeUtils.import usage
| Assignee | ||
Comment 6•5 years ago
|
||
Depends on D97731
We used to delay those calls because they needed rootURI to be set. This is no longer necessary.
| Assignee | ||
Comment 7•5 years ago
|
||
Depends on D97732
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 8•5 years ago
|
||
Can I have a talos push to try to see if it's not breaking aything?
Any regressions expected?
| Assignee | ||
Comment 9•5 years ago
•
|
||
Fission build failing on netmonitor since this doesn't include the workaround for the netmonitor test (Bug 1574417).
I'm also waiting for more results to see if the changes introduce any difference in the baselines of the tests.
I will request reviews from DevTools peers when this is ready for review.
| Assignee | ||
Comment 10•5 years ago
|
||
I didn't notice the reviewer group was automatically flagged even when there are no reviewers set by the patch author. I will set the patches as changes planned for now.
Comment 11•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 12•5 years ago
|
||
There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:jdescottes, could you have a look please?
For more information, please visit auto_nag documentation.
| Assignee | ||
Comment 13•5 years ago
|
||
Will address final review comments and land this asap.
Comment 14•5 years ago
|
||
Comment 15•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/fd09dd26dda7
https://hg.mozilla.org/mozilla-central/rev/08bd3a0bbfe1
https://hg.mozilla.org/mozilla-central/rev/aa690fe1bad7
https://hg.mozilla.org/mozilla-central/rev/d88937631d65
https://hg.mozilla.org/mozilla-central/rev/9f036835186c
Description
•