1217262 - Allow JS-implemented Web IDL objects to be created against a non-window scope

Status: RESOLVED WONTFIX

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

Description

[Boris Zbarsky [:bzbarsky]]

In particular, right now we tell a JS-implemented object about its associated global via the nsIDOMGlobalPropertyInitializer setup, which takes an nsIDOMWindow.  But some objects (e.g. for bug 1215591) would like to be creatable from system globals.

The way I see it, we have two main options:

1)  Change nsIDOMGlobalPropertyInitializer to take nsISupports (since nsIGlobalObject is not scriptable).

2)  Add a new interface taking nsISupports and QI to it in addition to nsIDOMGlobalPropertyInitializer.

I somewhat prefer option (1), I think; I expect it to be compatible-enough.  Any objections?

Comment 1

[Peter Van der Beken [:peterv]]

Option 1 seems fine, though I think we're trying to move away from JS-implemented DOM objects.

Comment 2

[Bobby Holley (:bholley)]

Yeah, seems like we should WONTFIX this given that js-implemented WebIDL is deprecated?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Sure, but we have existing JS-implemented things and they're a pain to use for people right now... So unless we have a concrete plan for reimplementing them, it might be worth making their use be less footgunny.

Comment 4

[Boris Zbarsky [:bzbarsky]]

That said, for the particular case of RTCPeerConnection even if we changed the C++ bits we'd then land at https://searchfox.org/mozilla-central/rev/62a130ba0ac80f75175e4b65536290b52391f116/dom/media/PeerConnection.jsm#419-421 and later things like https://searchfox.org/mozilla-central/rev/62a130ba0ac80f75175e4b65536290b52391f116/dom/media/PeerConnection.jsm#424 would throw, and you wouldn't have it working anyway. So this change would be necessary to allow things like bug 1215591 but definitely not sufficient.

Comment 5

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #3)

Sure, but we have existing JS-implemented things and they're a pain to use for people right now... So unless we have a concrete plan for reimplementing them, it might be worth making their use be less footgunny.

Fair, but we should definitely compare the cost of doing more work on this infrastructure against the cost of reimplementing the WebRTC stuff in native code. That's really the last big consumer of this deprecated machinery, so I'm more keen on fixing that than fixing the machinery.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Fair. Given that bug 1215591 got resolved for now, let's wonfix this.