457596 - loading resources with Cu.import during xpcom registration fails

Status: NEW

(Core :: XPConnect, defect)

Description

[Shane Caraveo]

I've created an extension, which has resources (js modules) and javascript xpcom components that load them using Components.utils.import.  

During xpcom registration, the first js xpcom component that is registered will fail to load the extensions resources, but subsequent components getting registered can load them.  This is not an issue with loading gre modules (eg. XPCOMUtils.jsm).

I've tracked this down to nsIResProtocolHandler::GetSubstitution not having the resource mapping (from chrome.manifest for the extension) for new installed extensions.  

I also am able to work around this by having a bogus component load first and fail so the real components can load the resource and register properly.  You can see further comments in the file:

http://svn.openkomodo.com/openkomodo/view/addons/sdconnector/components/anErrorLoading.js

I'm relying on the files to get registered during xpcom registration in alphabetical order (they do so on OSX) for the workaround to work.

Comment 1

[Philipp Kewisch [:Fallen][☁️📆]]

Using components to register the module is a really ugly workaround to my mind. I'd like to see this soon, I can imagine this causes headaches for extension developers that first have to do with modules.

Comment 2

[Shane Caraveo]

similar or same bug 459107 which has a different workaround.  I don't think that is the right fix, since it means any extension needing to have modules will need to replicate that code.  This should be handled on extension load, since the module directory is specified in chrome.manifest.