406538 - Allow using chrome:// URLs in Components.utils.import() for JS modules

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Wladimir Palant]

+++ This bug was initially created as a clone of Bug #398579 +++

The restriction to resource:// URLs limits the usefulness of Components.utils.import() considerably. I would like to use this feature in TomTom HOME but it would require moving JavaScript files out of a JAR file.

Bug 380970 talks about the requirement that the URL corresponds to an actual file on disk. From what I can see, this is mostly for reasons of hashing - any good reason why we cannot hash by URL? Other than that the file is passed to mozJSComponentLoader::GlobalForLocation() which should be able to take a URL and read from a stream (similar to mozJSSubScriptLoader). One issue is the __LOCATION__ property set in components - but setting it for file:/// URLs only should be acceptable. The other is the XPCONNECT_STANDALONE flag - I am not sure which configuration uses it but if we don't have NS_GetURLSpecFromFile() there we might have other issues working with URLs as well.

Comment 1

[Jez]

For what it's worth, I've just come across this, and add my voice to the call for the ability to use chrome:// URIs with JS modules.  Until that's possible they can't be imported from a .jar, which sucks.

Comment 2

[Dave Garrett]

(In reply to comment #1)
> Until that's possible they can't be imported from a .jar, which sucks.

Yes, this is quite annoying. It just throws NS_ERROR_UNEXPECTED at you when you resource:// to a file in a JAR. You can dump the URL in the address bar and it loads up fine, so why is it acting different here?

Comment 3

[gg0687644]

This bug complicates the build process by having to exclude the modules from the jar packaging. At least, please include this information in  https://developer.mozilla.org/en/Using_JavaScript_code_modules, so that developers are alerted beforehand instead of unpleasant surprise.

Comment 4

[Dave Garrett]

(In reply to comment #3)
> At least, please include this information in 
> https://developer.mozilla.org/en/Using_JavaScript_code_modules, so that
> developers are alerted beforehand instead of unpleasant surprise.

Done. Borrowed a tiny bit from this, which already noted it:
https://developer.mozilla.org/en/Components.utils.import

Comment 5

[Alex Vincent [:WeirdAl]]

If someone can tell me how to safely ensure the chrome URI points to something local, I'd be willing to take a stab at it.  (It makes sense for me to do it, since I'm the one that "fixed" the two bugs in comment 0).

https://bugzilla.mozilla.org/show_bug.cgi?id=398579#c7 still needs to be answered, in other words.

Comment 6

[Alex Vincent [:WeirdAl]]

I think I've figured it out.

(1) If it's a chrome: URI, we can ask the chrome registry to resolve the URI to another type.  JS sample: http://hg.mozilla.org/mozilla-central/annotate/1bcf90daba66/chrome/test/unit/test_data_protocol_registration.js#l83

(2) The resolved URI will most likely be a nsStandardURL, constructed with an argument, aSupportsFileURL.  If and only if this argument is true, the URI will QI to nsIFileURL.  (resource, file protocols do this, data does not.)

(3) From there, if we can find a file from nsIFileURL, we're good.

Comment 7

[Alex Vincent [:WeirdAl]]

Also,

nsCOMPtr<nsIJARURI> jar = do_QueryInterface(uri);
while (jar)
{
  rv = jar->GetJARFile(getter_AddRefs(uri));
  NS_ENSURE_SUCCESS(rv, rv);
  jar = do_QueryInterface(uri);
}

This would be for the case where chrome:// -> jar:...

Comment 8

[Alex Vincent [:WeirdAl]]

Meh, this code doesn't allow for reading inside zip archives:

        rv = GlobalForLocation(componentFile, &newEntry->global,
                               &newEntry->location, &exception);

It'd be easier if we had a GlobalForURI function.  This part is scary to me, stuff I don't want to do.

Comment 9

[Michael Wu [:mwu]]

Should be fixed by bug 552121 (omnijar). Try mozilla-central. Components.utils.import from jars should just magically work now.

Comment 10

[Michael Wu [:mwu]]

Actually, I might not have tested chrome uris specifically, but they *should* work. In general, any URI that ends up being resolved as a fileuri or jaruri should work. Please reopen if it doesn't work.

Comment 11

[Ben Bucksch (:BenB)]

Weeee! Thanks!

Comment 12

[Philipp von Weitershausen [:philikon]]

I can confirm that Cu.import()ing JS modules from chrome:// URIs (including those that point to JAR'ed files) works nicely. Thanks!

Comment 13

[Brendan Eich [:brendan]]

:mwu ftw!

/be

Comment 14

[Eric Shepherd [:sheppy]]

Documentation updated here:

https://developer.mozilla.org/en/JavaScript_code_modules/Using_JavaScript_code_modules#Locating_the_code_module

And listed on the Firefox 4 for developers page.

Comment 15

[Dave Garrett]

Added the note here as well:
https://developer.mozilla.org/en/Components.utils.import