- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Sat, 01 Oct 2016 00:33:09 +0000
- To: public-webrtc@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