(In reply to Rob Wu [:robwu] from comment #2)
Do you anticipate any usage of this outside of devtools?
If not, then it might be more effective to:
- if loadInDevtoolsLoader is passed, use that value. This allows the entry point to enter the devtools loader, or a specific devtools module already loaded through the devtools loader to opt out of it.
Yes the boolean would be important for the first entry point where we pass
loadInDevtoolsLoader: true. This is the falsy value which would become useless if we introduce a list of module URIs.
- if not, check if the global is the devtools global, check whether the module URL starts with "resource://devtools/"
I would have done that right away if that was this simple ;)
Unfortunately doing this prevents debugging ESM correctly.
The typical example is about putting a breakpoint in XPCOMUtils. The breakpoint will be trigerred when devtools calls this shared XPCOMUtils module.
With this issue in mind, I believed it was better to special case the singleton modules and allow the best debugging experience for all the other modules by default.
But may be this should be the other way around given that the concept of ESM being singleton is strong. May be DevTools should explicitly mention the ESM that should be forked into the devtools loader??
In any case, using a generic pattern like URI doesn't work. We have to be explicit one way of another.
(In reply to Julian Descottes [:jdescottes] from comment #3)
For the record I think we should move webext to use something else than --start-debugger-server + RDP requests to install addons. This codepath is mostly intended for the Browser Toolbox.
May be it is worth opening a dedicated bug for this?
I think the current discussion about
loadInDevtoolsLoader is relevant regardless of webext usage of devtools.
(and the other way around having webext use more reliable way to install addons is relevant regardless of the module loader)