Disallow possibly-unsafe JS-implemented things

RESOLVED WORKSFORME

Status

()

Core
DOM
RESOLVED WORKSFORME
5 years ago
7 months ago

People

(Reporter: bz, Assigned: mccr8)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

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.
(Assignee)

Comment 1

5 years ago
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?
(Assignee)

Comment 3

5 years ago
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.

Comment 5

5 years ago
Doesn't PeerConnection use callbacks just because it isn't an EventTarget as it should be.
(Assignee)

Comment 6

5 years ago
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
(Assignee)

Updated

5 years ago
No longer blocks: 823512
No longer depends on: 870219
(Assignee)

Updated

5 years ago
Assignee: nobody → continuation
(Assignee)

Comment 7

3 years ago
Has this all been fixed now?
The slaughterhouse Xray work should make this mostly a non-issue, yes.
(Assignee)

Updated

7 months ago
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.