Closed Bug 858741 Opened 11 years ago Closed 7 years ago

Disallow possibly-unsafe JS-implemented things


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

Not set





(Reporter: bzbarsky, Assigned: mccr8)


(Blocks 1 open bug)


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.
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.
OK.  Do we just want to disallow the above for now until we've made them safe?
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.
(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.
Doesn't PeerConnection use callbacks just because it isn't an EventTarget as it should be.
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__.
Blocks: 823512
No longer blocks: 823512
Depends on: 870219
No longer depends on: 870219
Assignee: nobody → continuation
Depends on: 923904
Has this all been fixed now?
The slaughterhouse Xray work should make this mostly a non-issue, yes.
Closed: 7 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.