Closed Bug 837280 Opened 11 years ago Closed 10 years ago

The default module loader can't find the chrome module (or probably any preset modules)

Categories

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

x86_64
Windows 8
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mossop, Assigned: jsantell)

References

Details

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.
My blog post has a workaround to solve this but we should fix this in the loader.

https://www.oxymoronical.com/blog/2013/02/The-Add-on-SDK-is-now-in-Firefox
Depends on: 858278
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.
@resource://gre/modules/commonjs/sdk/console/traceback.js:12
@resource://gre/modules/commonjs/sdk/util/deprecate.js:11
@resource://gre/modules/commonjs/sdk/lang/functional.js:16
@resource://gre/modules/commonjs/sdk/event/target.js:14
@resource://gre/modules/commonjs/sdk/selection.js:18
@Scratchpad/1:20
*/


Does selection just have different requirements, causing the workaround from the blogpost to not apply? Is something else broken?
Assignee: nobody → jsantell
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!
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.