Closed Bug 781615 Opened 9 years ago Closed 7 years ago

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


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

Windows 7
Not set





(Reporter: jcranmer, Unassigned)



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).
Peter, what's a good way of doing this?
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.
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....
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:
> (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.
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.
Blocks: 790855
Blocks: 795544
See Also: → 859901
No longer blocks: 790855
I'm going to claim that bug 1073124 pretty much fixed this.  People should file bugs on particular things they want exposed.
Closed: 7 years ago
Depends on: 1073124
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.