858741 - Disallow possibly-unsafe JS-implemented things

Status: RESOLVED WORKSFORME

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

Description

[Boris Zbarsky [:bzbarsky]]

There are several WebIDL types that are reflected as raw JS objects in JS:

1)  any
2)  object
3)  Callbacks
4)  Callback interfaces
5)  Typed arrays

Exposing raw content JS objects to chrome runs some risk of chrome getting confused by the things they return.  So Bobby is not convinced we should do it.  Instead he proposes we coden some sort of wrapper around callbacks and callback interfaces.  In particular, what's needed is some sort of type-coercion on return values and property values.  So maybe for now we can allow void callback functions and void-return-value methods on callback interfaces, as long as we make sure to NOT end up with Xrays here.

For "object" and "any", are we really any worse off than in C++-implemented DOM?

For typed arrays, similar, actually...  Note that we _would_ make sure the chrome was getting an actual cross-compartment wrapper for a typed array, not some other sort of object.

Comment 1

[Andrew McCreight [:mccr8]]

This sounds like a good idea.  For similar reasons, I was not planning on supporting the ability of implementors the global property initializer to stick random objects on navigator.

Comment 2

[Boris Zbarsky [:bzbarsky]]

OK.  Do we just want to disallow the above for now until we've made them safe?

Comment 3

[Andrew McCreight [:mccr8]]

Given that there are currently 0 consumers of this, sure.

Reuben, does Contacts need any of the above?

WebRTC's PeerConnection appears to use callbacks all over the place, but none of the other stuff.

Comment 4

[Reuben Morais [:reuben]]

(In reply to Andrew McCreight [:mccr8] from comment #3)
> Reuben, does Contacts need any of the above?

As long as we have Date and arrays, no. Bug 742206, bug 851726.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Doesn't PeerConnection use callbacks just because it isn't an EventTarget as it should be.

Comment 6

[Andrew McCreight [:mccr8]]

PeerConnection uses the following callbacks as arguments:
  callback RTCPeerConnectionErrorCallback = void (RTCError error);
  callback RTCSessionDescriptionCallback = void (RTCSessionDescription sdp);
So we'll have to safely support those.  That does seem to fall under bz's suggested starting scope in comment 0.  The use of some of these callbacks in the existing code involves __exposedProps__.

Comment 7

[Andrew McCreight [:mccr8]]

Has this all been fixed now?

Comment 8

[Bobby Holley (:bholley)]

The slaughterhouse Xray work should make this mostly a non-issue, yes.