1621580 - moz-extension:// URLs cannot be imported with ChromeUtils.import() when loaded from an XPI

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, defect)

Description

[Geoff Lankow (:darktrojan)]

I can call fetch("moz-extension://xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/manifest.json") and it will succeed if the extension is unpacked, but fail if the extension is packed. (This isn't actually what I'm trying to do but it's a good enough test case.)

This seems to be the case whether extensions.webextensions.remote is set to true or false.

Comment 1

[Rob Wu [:robwu]]

1. How does manifest.json look like? In particular, what is inside the web_accessible_resources and permissions keys?
2. Where are you calling fetch?

Comment 2

[Geoff Lankow (:darktrojan)]

At the moment, I'm just doing all this from the devtools toolbox. (In Thunderbird, but the same is true in Firefox.)

I've just done some further investigation and it seems that the presence of an experiment_apis key causes the problem. Remove the key and everything seems to work fine, except then I can't have an experiment, which is what I'm trying to work on in the first place…

Comment 3

[Rob Wu [:robwu]]

Please attach a full test case and exact steps to reproduce the issue.

Comment 4

[John Bieling (:TbSync)]

Attachment: ff_exp.xpi

This WebExtension Experiment shows the described behaviour. Reproducable in FireFox Nightly 76.0a1 (2020-03-11). To run Experiments, you have to set

xpinstall.signatures.required = false
extensions.experiments.enabled = true

If this WebExtension gets installed unpacked via add-on debugging, everything works as expected and you will see

Loading myModule.jsm
WebExtensions: Hello world! <1>

in the main console. If it gets installed as a packed xpi directly, you will see

Error: An unexpected error occurred background.js:3:23

in the console of the add-on itself. If the import of myModule.jsm is removed (and all references to myModule), it runs thru without error.

Comment 5

[Andrew Swan [:aswan]]

I don't know enough about the guts of the module loader and the moz-extension handler to know why this doesn't work, but if you switch the getURL() call to something like context.extension.rootURI.resolve("./modules/myModule.jsm") that should give you a file: or jar: url (depending on whether the extensions is packed or not) that works with the module loader.

Comment 6

[Tomislav Jovanovic :zombie]

Loading custom modules from extension experiments isn't a thing we want to support. Andrew gave you some workarounds, or if that doesn't work, you might need to setup an URI substitution and map it to a resource:// URI before loading a JSM.

Comment 7

[John Bieling (:TbSync)]

Thanks for your help!

Using context.extension.rootURI.resolve() fixes this for us. Just to have a second tool available: How do I setup a URI substitution to map it to a resource:/ URI ?

Comment 8

[Tomislav Jovanovic :zombie]

Something like this:
https://searchfox.org/mozilla-central/rev/278046367d/toolkit/components/extensions/Extension.jsm#82-86
https://searchfox.org/mozilla-central/rev/278046367d/toolkit/components/extensions/Extension.jsm#2703,2737