Last Comment Bug 837280 - The default module loader can't find the chrome module (or probably any preset modules)
: The default module loader can't find the chrome module (or probably any prese...
Product: Add-on SDK
Classification: Client Software
Component: General (show other bugs)
: unspecified
: x86_64 Windows 8
P1 normal (vote)
: ---
Assigned To: Jordan Santell [:jsantell] [@jsantell]
Depends on: 858278
  Show dependency treegraph
Reported: 2013-02-01 13:53 PST by Dave Townsend [:mossop]
Modified: 2014-01-30 13:56 PST (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Dave Townsend [:mossop] 2013-02-01 13:53:36 PST
If a module, say sdk/notifications attempts to require("chrome") the default resolve function for the loader decides to try to load that as sdk/chrome, which fails.
Comment 1 User image Dave Townsend [:mossop] 2013-02-14 11:47:17 PST
My blog post has a workaround to solve this but we should fix this in the loader.
Comment 2 User image Wes Kocher (:KWierso) 2013-05-08 04:00:49 PDT
So, using the code from that blog post, it works just fine if you require("sdk/notifications"), but it fails when I try to require("sdk/selection"), with Scratchpad logging the following error:

Exception: Trying to load a non-local URI.

Does selection just have different requirements, causing the workaround from the blogpost to not apply? Is something else broken?
Comment 3 User image Jordan Santell [:jsantell] [@jsantell] 2014-01-30 13:56:49 PST
With the merging of bug 858278, "chrome" usage outside of the SDK environment now works and is tested.

Wes, regarding sdk/selection failing, that looks due to console/traceback usage, which includes toolkit/loader circular deps, requiring to explicitly map toolkit/loader in the loader constructor.

Bug 961194 should fix that!

Note You need to log in before you can comment on or make changes to this bug.