We are implementing Promise in the DOM due to limitations of SpiderMonkey. It should be exposed on every global object by default without using something like Cu.importGlobalProperties or wantGlobalProperties as if it is one of standard ES objects.

See comment #0 on the rationale for adding a property to the global object.

Comment on attachment 8397901 [details] [diff] [review] patch Review of attachment 8397901 [details] [diff] [review]: ----------------------------------------------------------------- I still have some misgivings about exposing the whole world of WebIDL to Sandboxes where we didn't previously, but in theory it's only a matter of time. So I'm tentatively ok with it, if Boris is. ::: dom/contacts/tests/test_migration_chrome.js @@ +21,5 @@ > DB_NAME, > ContactService, > Promise > } = imports; > +Object.freeze(imports); This hack (here and elsewhere) needs some explanation. ::: js/xpconnect/src/Sandbox.cpp @@ +1009,5 @@ > > bool > xpc::GlobalProperties::Define(JSContext *cx, JS::HandleObject obj) > { > + if (!dom::PromiseBinding::GetConstructorObject(cx, obj)) Please add a boolean for this, just like everything else, and default it to true in the GlobalProperties constructor. That way, people can still switch it off if they like. ::: js/xpconnect/tests/unit/test_promise.js @@ +3,5 @@ > + sb = new Cu.Sandbox('http://www.example.com'); > + sb.do_check_eq = do_check_eq; > + Cu.evalInSandbox('do_check_eq(typeof new Promise(function(resolve){resolve();}), "object");', > + sb); > + do_check_eq(typeof new Promise(function(resolve){resolve();}), "object"); And add some tests here to make sure that Promise can be switched off.

Comment on attachment 8397901 [details] [diff] [review] patch sr=me, though I'd _really_ like comments explaining what's going on with Object.freeze there.

OK, now with those comments the "freeze" makes no sense, at either of the callsites. It's freezing the RHS of the assignment in the one case, and the Promise object itself in the other case, which is totally different from what the "const" did! Can you explain what you're trying to do there?

I was trying to prevent Promise from being deleted or replaced accidentally.

That's not what Object.freeze(Promise) does, though. Here's a simple testcase: var Promise = {}; Object.freeze(Promise); Promise = 5; alert(Promise); this alerts 5.

Will this code work?

Comment on attachment 8399373 [details] [diff] [review] Followup: fix bogus constification code Yes, that's more like it!

Thanks for the review. https://hg.mozilla.org/integration/mozilla-inbound/rev/3d28b17b283c