785891 - Simple API for registering chrome substitutions

Status: RESOLVED DUPLICATE of bug 559306

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

It's fairly simple to register new resource URIs by registering appropriate substitution like file:///path/to/foo/ -> resource://foo/

    let ioService = Components.classes['@mozilla.org/network/io-service;1'].
                    getService(Components.interfaces.nsIIOService)
    let resourceHandler = ioService.getProtocolHandler('resource').
                          QueryInterface(Components.interfaces.nsIResProtocolHandler)
    resourceHandler.setSubstitution('foo', ioService.newURI('file:///path/to/foo/', null, null))

   
On the other hand registering mappings for chrome protocol is way more complicated:


1. One needs to create some directory like: /foo.manifest/
2. Create `chrome.manifest` file with content like: `content foo file:///path/to/foo/`
3. Register folder with created manifest:
   `Components.manager.addBootstrappedManifestLocation('/path/to/foo.manifest/')`

It looks like `addBootstrappedManifestLocation` https://mxr.mozilla.org/mozilla-central/source/xpcom/components/nsComponentManager.cpp#1772 ends up saving mapping in a hash map
http://mxr.mozilla.org/mozilla-central/source/chrome/src/nsChromeRegistryChrome.cpp#796 having some API
exposed to JS side to do just that would be a lot better and efficient. I'm thinking of `nsIChromeProtocolHandler` similar to existing `nsIResProtocolHandler`
http://xulplanet.mozdev.org/references/xpcomref/nsIResProtocolHandler.html

Comment 1

[Dave Townsend [:mossop] (PTO until Aug 21st)]

Why do we need this?

Comment 2

[Alexandre Poirot [:ochameau] [PTO back August 21]]

Seems like a duplicate of bug 725127.

Comment 3

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

(In reply to Alexandre Poirot (:ochameau) from comment #2)
> Seems like a duplicate of bug 725127.

That is just one, but not only use case for this. Personally I run into issue with writing wrapper for new async IO API that needs to use ChromeWorker that can be inited only with js file coming from chrome URI.

Also we were talking about replacing `resource` URIs used now with somethig else that sites can't sniff for. This would allow us to naturally switch from it to `chrome` instead.

There were many other limitations we've being running into for not using `chrome` URIs, but I can't remember them right now.

Comment 4

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

BTW I also have realized that my proposed API is not quite right either, as typically for chrome URIs you register subsections like:

content foo file:///path/to/foo/
skin foo file:///path/to/foo-skin/
locale bar file:///path/to/bar/

Never the less, requested functionality is still relevant and API can be adjusted. I also have implemented ugly JS solution https://gist.github.com/3493210 to be able to make progress on new async OS.File wrapper API. Hopefully we'll be able to remove ugly hacks used there once this is fixed.