W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2016

[webrtc-pc] Not clear how data channel errors are reported, with ErrorEvent interface.

From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
Date: Sat, 01 Oct 2016 00:33:09 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-180427624-1475281987-sysbot+gh@w3.org>
taylor-b has just created a new issue for 
https://github.com/w3c/webrtc-pc:

== Not clear how data channel errors are reported, with ErrorEvent 
interface. ==
The `RTCDataChannel` has an `EventHandler` of type `error`, which uses
 the `ErrorEvent` interface. However, this interface is used for 
reporting script errors associated with specific line/column numbers. 
So for an error that originates from background processing, it doesn't
 really make sense (to me). Do we just leave those attributes as the 
defaults?

In looking for an answer, the text that describes firing an error is 
somewhat lacking. It's simply:

> Fire a NetworkError event at _channel_.

Which I can extrapolate to mean:

> Fire an event named "error" which does not bubble, is not 
cancelable, and which uses the ErrorEvent interface with _message_ set
 to a user agent defined string (fingerprint warning?), with 
_filename_, _lineno_ and _colno_ left as the default values, and with 
_error_ set to a newly 
[created](https://heycam.github.io/webidl/#dfn-create-exception) 
NetworkError.

Is that what we want?

It looks like this topic also came up with mediacapture-main 
(https://github.com/w3c/mediacapture-main/issues/337), and the 
solution there was to use a simple event. But in this case we do want 
additional error information, or at least I assume.

If RTCDataChannels are meant to be similar to WebSockets, could we do 
the same thing they do, and put the additional information on the 
close event (in their case, a code and reason)?

Please view or discuss this issue at 
https://github.com/w3c/webrtc-pc/issues/846 using your GitHub account
Received on Saturday, 1 October 2016 00:33:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:49 UTC