Intent to Implement & Ship: RTCError, RTCErrorEvent, RTCErrorEventInit

[Henrik Boström]

Contact emails

hb...@chromium.org

Explainer

The RTCError object is used to define errors that are thrown in WebRTC or that are fired by RTCErrorEvent. They are used by APIs such as:

- RTCPeerConnection.setLocalDescription() and setRemoteDescription(), these are currently shipped to throw InvalidAccessError when they should throw RTCError due to parse errors. The error would change from a DOMException named "InvalidAccessError" to an object whose name attribute is "RTCError".

- RTCRtpSender.setParameters(), currently shipped to throw various DOMExceptions, should in some cases throw RTCError and in some cases DOMException OperationError. This may change the ".name" of the object in some cases.

- RTCDataChannel.onerror, currently shipped to throw an Event of type "error", this should be an RTCError. Here the type does not change, the event fired just gets an additional attribute containing an RTCError with more information, so this should be a minor addition.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Risks

Interoperability and Compatiblity

Different browsers seem to throw different things, for example Firefox ESR throws InvalidSessionDescriptionError. 

All major browsers have committed to WebRTC 1.0.

Ergonomics

This is part of RTCPeerConnection and related APIs. Performance concerns are N/A.

 

Activation 

N/A

Is this feature fully tested by web-platform-tests?

There is test coverage for the existence of the error/event and the constructors. There should be test coverage added for particular APIs (listed above) throwing this particular error, which I'd be happy to add as part of implementing this.

Entry on the feature dashboard

https://www.chromestatus.com/feature/5726490620592128

[Philip Jägenstedt]

A quick look in http://web-confluence.appspot.coms suggests that nobody else has shipped this yet, but it has been around for a long time in the spec.

Will this expose any new information or will it just change the interfaces used? I ask because if the bits in https://w3c.github.io/webrtc-pc/#rtcerrordetailtype-enum are newly exposed I wonder if there are privacy/security implications? +Mike West can you triage?

https://w3c.github.io/webrtc-pc/#rtcerror-object is a bit unusual in the same way as DOMException, in that it's not defined in Web IDL. Will this be implemented with custom bindings or what sort of magic is needed to match the spec here?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7769b2c1-e506-4195-acd1-7874190e2ef4%40chromium.org.

[Henrik Boström]

It gives more detailed error reasons, e.g. RTCErrorDetailType or sdpLineNumber. Previously you could only rely on the human-readable error message that is non-standard.

The plan is to implement this as an interface, similarly to how OverconstrainedError was implemented, to avoid custom binding magic: see discussion at https://crbug.com/769726.

+hta: Do you have any comments with regards to privacy/security implications?

[Philip Jägenstedt]

Do you know why this isn't defined using Web IDL in the spec if it's still workable to implement it using Web IDL?

+Domenic Denicola and +Yuki Shiino from https://crbug.com/769726 in case you have thoughts.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0eb865ad-268b-493d-8e7b-6beb4e4c9eb7%40chromium.org.

[Henrik Boström]

I'm having trouble even figuring out what the difference is between a WebIDL interface version and an "intrinsic object" as defined in the spec.

[Harald Alvestrand]

The discussions around how we define error objects were last held in the Lisbon TPAC, so it's a bit rusty in my mind now.

At the time, we were told that:

a) DOMError wasn't really extensible to provide "error name + message + error-specific stuff"

b) An error object couldn't be defined in WebIDL because of reasons I think I understood at the time, but wouldn't be able to reproduce now

c) Therefore, if we wanted error objects with extra data in the spec at that time, we'd have to define them ourselves, but couldn't use WebIDL for the purpose

The result was that we added OverconstrainedError to mediacapture-main and RTCError to webrtc-pc, using language that was largely lifted from ECMAScript's definition of DOMError (which isn't done using WebIDL either).

It's been sitting there since then, waiting for someone to implement it; nobody's suggested trying to challenge the dictum that "error codes can't be in WebIDL" in the spec forum.

WRT privacy/security: The information exposed (SDP line number, whether the error was a DTLS certificate mismatch or a DTLS remotely-signalled error, and so on) are reasonably innocuous as far as I can tell. They give slightly more machine-parseable information about error states, which could be extremely useful in debugging (if returned correctly), and probably also give some limited fingerprinting surface (but probably a subset of the fingerprinting surface of the human-readable strings we currently return in order to give additional error information).

So I don't think it's a big deal, security/privacy wise.

[Yuki Shiino]

Considering that almost all of Web APIs are defined to throw ECMAScript error (such as TypeError) or DOMException (defined in Web IDL), I'm not sure if it's a really good idea to throw something else.  If only the purpose is to provide more information about error/failure, there might be other options.

One of possible options is to create a stateful object (often called "session"), and update the state of the object and/or store detailed error information in the object.  XHR follows this pattern, I think.

    let xhr = new XMLHttpRequest(...);

    // |xhr| is an object that represents a "session".

    xhr.readyState;

    xhr.status;

    // We can access its state via several APIs.

We can apply this pattern not only to asynchronous cases, but also to synchronous cases.  For example,

    let session = domObj.newSession(...);

    try {

      session.performX();

    } catch (e) {

      console.error(session.detailedError);

    }

Depending on cases, |domObj| itself can be considered as "session" (or it's okay that |domObj| is stateful) and then there is no need to introduce a new "session" object.  This approach has an advantage; you can tell the latest state anytime, including whether the last error is recovered or not, and such information would be useful even when an exception is not thrown.

Another option is to add a new member into DOMException in addition to name, message, and code.

    interface DOMException {

      readonly attribute DOMString name;

      readonly attribute DOMString message;

      readonly attribute unsigned short code;

      readonly attribute any data;  // NEW!!

    };

I think that we can come up with more options.

Cheers,

Yuki Shiino

2019年1月21日(月) 23:13 Harald Alvestrand <h...@google.com>:

[Harald Alvestrand]

Absolutely possible to consider other patterns, but that's something for the w3c wg, not an implementor choice - and the wg made its decision long ago.

[Boris Zbarsky]

On 1/21/19 9:13 AM, 'Harald Alvestrand' via blink-dev wrote:
> b) An error object couldn't be defined in WebIDL because of reasons I
> think I understood at the time, but wouldn't be able to reproduce now

Taking a quick look at how RTCError is defined, the following are the
bits that are not doable in Web IDL right now, as far as I can see:

1) Having %Error% as the prototype of the RTCError constructor.
2) Having %ErrorPrototype% as the prototype of RTCError.prototype.
3) Having the RTCError constructor create a new object when its [[Call]]
is invoked (as opposed to its [[Construct]]).
4) Having all the properties have useful values on RTCError.prototype.

Item 2 is similar to what
https://heycam.github.io/webidl/#es-DOMException-specialness defines
(and is something I have in the past proposed as a Web IDL extended
attribute, but didn't happen due to pushback from Chrome).

Item 1 is a subclassing sanity thing, and makes some sense; I've
proposed it for DOMException in the past but again there was pushback.

Item 3 is just a bad idea, imo; neither Web IDL objects nor newer ES
builtins (e.g. Map) work that way.

Item 4 is not really doable with Web IDL, but it's not clear to me how
integral it is to the definition of this error type.

All of which is to say that I personally would support extending IDL to
support the proto chain modifications described above, if that would
help. I suspect it would make the spec a lot less vague [1].

-Boris

[1] For example, it's not clear to me, once we get to
<https://w3c.github.io/webrtc-pc/#set-the-rtcsessiondescription> step 6,
what the "sdpLineNumber" property is supposed to look like. Is it an
accessor or a value property? Is it configurable? Writable?
Enumerable? None of that is defined, and it would need to be for this
spec to be interoperably implementable.

[Philip Jägenstedt]

This all quite special as expected. I had assumed that item 1 was
already done for DOMException and that's why it's also done for
RTCError, but apparently not. But item 2 is what makes `new
DOMException() instanceof Error` true, and is what I've assumed is the
thing that really matters.

hbos@, with your implementation, can you check if `new RTCError(...)
instanceof Error` is true? I'd expect that to only work with custom
bindings.

[Domenic Denicola]

I agree there are better patterns to consider here. Both of Yuki's suggests are good, as is just defining a new type that inherits from DOMException. I think the WG made a strange choice here, and I suggest that Chrome as an implementation push back on the current design, instead of shipping it.

[Philip Jägenstedt]

Are there examples of other types that inherit from DOMException? I
presume that this would require roughly the same type of prose as is
currently used to define both DOMException and RTCError?

[Domenic Denicola]

There are no other types that do so; all other specs have used other patterns (mostly the session object pattern).

But, it would not require any extra prose. These days DOMException is an IDL-defined interface, so you can just inherit from it like other IDL-defined interfaces.

[Philip Jägenstedt]

Oh, so DOMException is already possible to inherit from in plain IDL? I would not have guessed that, that seems very convenient.

hbos@, do you think doing that would make sense? It would add DOMException to the prototype chain, but maybe that's fine? Or good?

[Yuki Shiino]

The idea of inheriting DOMException looks interesting and feasible to me.  Probably it's a good idea.

2019年1月23日(水) 8:28 Philip Jägenstedt <foo...@chromium.org>:

[Harald Alvestrand]

I'll raise that proposal with the WG. Domenic, I'll CC you on the bug, and you can chime in.

I don't think this was possible in Lisbon, I don't know when that changed.

[Harald Alvestrand]

Filed https://github.com/w3c/webrtc-pc/issues/2082

Henrik, is it easy to change your proposed implementation to be defined like this?

[Henrik Boström]

Oh, I didn't think that was possible! Yes, implementing RTCError to extend DOMException was very easy.

[Daniel Bratell]

Where did we end up here? If I've understood the discussion correctly, having RTCError is just fine, but it wasn't plugged into the machinery in a consistent manner. Is that still true, or is everything just fine now? Specs and tests updated and so on?

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68e71512-dcbb-4927-b0ef-37ebdf4a7d6c%40chromium.org.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[hb...@webrtc.org]

Update: Everyone seem to be in agreement that RTCError should inherit from DOMException. I've updated the code and I have a pull request to change the spec, but I'm waiting for it to get reviewed and merged before I proceed.

[Henrik Boström]

The spec now says it extends DOMException. Requesting to ship!

[Philip Jägenstedt]

https://w3c.github.io/webrtc-pc/#dfn-rtcerror is the updated spec. LGTM1!

[Mike West]

LGTM2. Thanks for addressing the concerns raised in this thread!

-mike

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DersT_8N28Fe7ZFjGGkEf7Rkme421_LXV4%2B0fKQ9NYc4w%40mail.gmail.com.

[Henrik Boström]

On Fri, Feb 1, 2019 at 4:02 PM Mike West <mk...@chromium.org> wrote:

LGTM2. Thanks for addressing the concerns raised in this thread!

-mike

On Fri, Feb 1, 2019 at 4:01 PM Philip Jägenstedt <foo...@chromium.org> wrote:

https://w3c.github.io/webrtc-pc/#dfn-rtcerror is the updated spec. LGTM1!

Note: In https://w3c.github.io/webrtc-pc/#dfn-rtcerror says "interface RTCError" and not "interface RTCError : DOMException" because of a ReSpec issue, the PR wrote it as "interface RTCError /*: DOMException*/". This is purely editorial and will be addressed in the issue filed.

[Yuki Shiino]

Thanks for the spec work.  LGTM.

2019年2月2日(土) 0:13 Daniel Bratell <bra...@opera.com>: