No way to throw a spec'ed TypeError from jsimplemented webidl.

RESOLVED FIXED in Firefox 41

Status

()

Core
DOM
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: jib, Assigned: bz)

Tracking

Trunk
mozilla41
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox41 fixed)

Details

Attachments

(1 attachment)

There's reason to believe we'll need to throw TypeError as part of specs soon.

  https://github.com/w3c/mediacapture-main/issues/189
  https://github.com/w3c/webrtc-pc/issues/35

The rationale is that WebIDL can't cover everything when it comes to validation.

Now it looks like we're settling on SyntaxError in the second thread, but it raises an interesting problem nonetheless:

Our implementation appears not to allow an ES exception like TypeError thrown from jsimplemented webidl to make it to content the way a DOMException does.

When I throw new TypeError("This is a test.") from PeerConnection.js, I get:

> Web console:     NS_ERROR_UNEXPECTED:             mytest.js:22:0
> Browser console: This is a test.         PeerConnection.js:356:0
Created attachment 8621388 [details] [diff] [review]
Make it possible to throw TypeError from js-implemented webidl

This just allows throwing anything that comes from the content compartment, since bug 1173638 ensured that constructing an Error will properly principal-filter things so it won't expose anything it's not supposed to expose.  We keep the DOMError special case for now, but can consider removing it in a followup since now consumers can just directly throw an Error from the content compartment.
Attachment #8621388 - Flags: review?(bobbyholley)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Comment on attachment 8621388 [details] [diff] [review]
Make it possible to throw TypeError from js-implemented webidl

Review of attachment 8621388 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/bindings/BindingUtils.cpp
@@ +284,5 @@
>    MOZ_ASSERT(!mMightHaveUnreportedJSException,
>               "Why didn't you tell us you planned to handle JS exceptions?");
>  
> +  dom::DOMError* domError;
> +  nsresult rv = UNWRAP_OBJECT(DOMError, &mJSException.toObject(), domError);

Can you explain in a comment why we need the DOMError case?
Attachment #8621388 - Flags: review?(bobbyholley) → review+
> Can you explain in a comment why we need the DOMError case?

Done, and filed bug 1174954 on removing it.
https://hg.mozilla.org/mozilla-central/rev/6b384f04add8
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox41: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.