Closed Bug 859901 Opened 11 years ago Closed 10 years ago

Allow exposing Web IDL interfaces on the global object of JS components and the xpcshell global object

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1073124

People

(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)

References

(Blocks 1 open bug)

Details

We need to have a way of exposing some Web IDL interfaces such as XHR to the global object of JS components and xpcshell, so that we would not have to rely on XPIDL interfaces for using those APIs.  I could imagine that this could take the form of an attribute on the interface which we can use to opt in where exposing the Web IDL interface for those globals makes sense.  This is one of the things that we need to have in order to start banning the usage of XPIDL for new code completely.
We already do this for TextEncoder/TextDecoder, note.  For now it's just a hardcoded list.
Blocks: ParisBindings
Where's that list defined?
At the end of nsXPConnect::InitClassesWithNewWrappedGlobal
Thanks.  Now, could you please give me some pointers on how one could move that static list to be based on attributes on interfaces?  I'd like to take a stab at this but I've never done anything nearly this fancy in the Web IDL parser/codegen.  The most interesting bit of the puzzle to me is how I would codegen stuff into a "register" function which gets called from InitClassesWithNewWrappedGlobal...
That part should be pretty similar to how RegisterBindings gets generated right now, no?

In fact, the function could just go in that file...
You're right!  I guess modifying the parser to accept the additional attribute on the interface should be relatively easy.  I'll see if I can attack this some evening.

What should I name the new attribute?  ExposedToAllGlobals?
Assignee: nobody → ehsan
The parser just accepts all extended attributes for now, until I fix bug 859503.

Maybe DefineOnAllGlobals?
Why would we need an attribute for this? If we do this we should do it for all interfaces.
(In reply to comment #7)
> The parser just accepts all extended attributes for now, until I fix bug
> 859503.

Shoot, that has an r+'ed patch now.  ;-)

> Maybe DefineOnAllGlobals?

Sure.
(In reply to comment #8)
> Why would we need an attribute for this? If we do this we should do it for all
> interfaces.

But do we want to expose all of these interfaces for JS components and xpcshell?

(It could be that the answer is yes, I'm not really sure.)
> Shoot, that has an r+'ed patch now.  ;-)

Should be pretty simple to add to the whitelist.

> But do we want to expose all of these interfaces for JS components and xpcshell?

In some ways, yes.  What worries me is the setup time....
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #10)
> (In reply to comment #8)
> > Why would we need an attribute for this? If we do this we should do it for all
> > interfaces.
> 
> But do we want to expose all of these interfaces for JS components and
> xpcshell?

At a first pass, probably everything you get in workers as well. It's not clear to me how useful outright DOM members (like HTMLSelectElement) are, although things like DOMParser are still useful (read: I want DOMParser :-P).
(In reply to comment #12)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #10)
> > (In reply to comment #8)
> > > Why would we need an attribute for this? If we do this we should do it for all
> > > interfaces.
> > 
> > But do we want to expose all of these interfaces for JS components and
> > xpcshell?
> 
> At a first pass, probably everything you get in workers as well. It's not clear
> to me how useful outright DOM members (like HTMLSelectElement) are, although
> things like DOMParser are still useful (read: I want DOMParser :-P).

I'm not sure why whether something is present in workers should be a factor here.  We have tons of stuff we don't expose to the workers because of threading issues...
Yeah, let's not get carried away here. There are several blocking things (sync IndexedDB for example) that are designed only for workers and should never be available in main thread components. Adding a few constructors is probably enough, at least in the beginning. We just need a way to make it easy to extend the number of things we choose to expose.
We need to avoid creating multiple versions of our DOM. The split between workers and main-thread is annoying but it's unlikely to go away. But let's not create more sets of supported DOM interfaces. If the setup time is an issue we should look into using a resolve hook.
(In reply to comment #15)
> We need to avoid creating multiple versions of our DOM. The split between
> workers and main-thread is annoying but it's unlikely to go away. But let's not
> create more sets of supported DOM interfaces. If the setup time is an issue we
> should look into using a resolve hook.

OK then I guess I'll focus on registering all of the available interfaces in those globals for now.
(In reply to Peter Van der Beken [:peterv] from comment #15)
> The split between workers and main-thread is annoying but it's unlikely 
> to go away. 

IIRC, this happened now. What's the status here, then?
(In reply to Florian Bender from comment #17)
> (In reply to Peter Van der Beken [:peterv] from comment #15)
> > The split between workers and main-thread is annoying but it's unlikely 
> > to go away. 
> 
> IIRC, this happened now.

I'm not sure what you mean, that the split between workers and main-thread has gone away somehow?
Bug 1073124 fixed this.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.