781615 - Expose some DOM bindings to JS globals that don't have a window object

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Joshua Cranmer [:jcranmer]]

Some of the interfaces using the new DOM bindings (like the string decoding API of bug 764234) are useful to people implementing things in JS, even if there's no window object to be had (say, in a .jsm).

Comment 1

[Boris Zbarsky [:bzbarsky]]

Peter, what's a good way of doing this?

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Can we copy the way IndexedDB does this?  That would mean you get a hold of an xpcom service and ask it to put the relevant DOM objects on your global.

Comment 3

[Boris Zbarsky [:bzbarsky]]

There's some weirdness involving tracing of the proto array and such, right?

But if we solve that, and make sure all the relevant globals have a proto array, then we could in fact have a service that resolves a given DOM interface name or something....

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

I'm interested in this for letting the gaia e-mail app gain access to the TextEncoder/TextDecoder bindings being createde on bug 764234 using new-style DOM bindings.

Since the new-style DOM bindings tell nsScriptNameSpaceManager about themselves and nsScriptNamespaceManager also discovers all the category-registered things (ex: JavaScript-navigator-property), is the thing to do have a service do something like how they get created on the window?  Specifically, nsWindowSH::GlobalResolve appears to be the single point where the lookup is performed, the DefineDOMInterface method is triggered to get things all invoked, and Init is called (with a window that we would not have unless we implement some type of stubby window)?

nsWindowSH::GlobalResolve can be found here right now:
http://dxr.allizom.org/mozilla-central/dom/base/nsDOMClassInfo.cpp#l6743

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

> (with a window that we would not have
> unless we implement some type of stubby window)?

And by this, I meant to say that it's possible that some bindings might assume a window and get angry when they don't get one.  I believe indexedDB, for example, needed some changes before it could run safely without a proper window being the global.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Some binding _constructors_ certainly expect a window.

In terms of the service, the right thing depends on how many things we plan to expose.  There are hundreds to thousands of DOM interfaces exposed on Window, which is why we do the resolve hook thing and set them up lazily.  But if we'll only be exposing a few things in other cases, we could also eagerly define the ones we want to expose.  That's what workers do, for example.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I'm going to claim that bug 1073124 pretty much fixed this.  People should file bugs on particular things they want exposed.