Closed Bug 406538 Opened 13 years ago Closed 10 years ago

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

Categories

(Core :: XPConnect, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: ecfbugzilla, Unassigned)

References

Details

(Keywords: dev-doc-complete)

+++ 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.
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.
(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?
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.
(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
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.
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.
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:...
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.
Blocks: 531886
Summary: Allow using chrome:// URLs in Components.utils.import() → Allow using chrome:// URLs in Components.utils.import() for JS modules
No longer blocks: 531886
Blocks: 552855
Should be fixed by bug 552121 (omnijar). Try mozilla-central. Components.utils.import from jars should just magically work now.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
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.
Keywords: dev-doc-needed
Weeee! Thanks!
I can confirm that Cu.import()ing JS modules from chrome:// URIs (including those that point to JAR'ed files) works nicely. Thanks!
:mwu ftw!

/be
Depends on: omnijar
You need to log in before you can comment on or make changes to this bug.