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....
> (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.
I'm going to claim that bug 1073124 pretty much fixed this. People should file bugs on particular things they want exposed.
Status: NEW → RESOLVED
Closed: 5 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.