Re: [File API] Issue 182 about OperationNotAllowed

On Mon, Oct 3, 2011 at 6:00 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Mon, 3 Oct 2011, Jonas Sicking wrote:
>>
>> I looked at how for example WebSockets and EventSource exposes error
>> information. I would have thought in both cases that it would have been
>> done as a property on the websocket/eventsource object itself. However I
>> couldn't find any such property, and since the "error" events fired by
>> both specifications are simple Events it doesn't appear as if the
>> information is exposed on the event object either.
>>
>> Do neither of these specifications make error information available?
>
> Web Sockets exposes error information in the 'close' handler, if that
> counts. That's unrelated to exceptions, though. It uses a custom event
> interface type.
>
> Generally speaking I try to avoid exposing too much error information to
> script (as opposed to the developer console) because it can often lead to
> security problems (e.g. leaking information about intranet topology).
>
> HTMLMediaElement exposes error state on a .error attribute that returns a
> MediaError object (or null), which itself just has a single .code
> attribute currently, that being a value from 1 to 4 (corresponding to some
> defined constants). At some point in the future it may be extended to
> provide more information in the object, but there are no immediate plans
> to do so. In any case, this is also not an exception, and no attempt is
> made to keep these codes synced with the exception codes.
>
> All exception handling in the HTML spec uses the DOM Core behaviour.

I agree that exposing error information can be a problem. However it
seems like this is safe enough in specs where we use CORS or similar
explicit-opt-in protocols. In those cases I think it's generally a
good idea to expose error info to pages.

So MediaError is exactly the type of thing that I'm talking about that
we might want to move into the DOM4 spec. We have the same thing in
the File API spec. The FileError interface is just a plain object with
a single .code property. We're planning on moving that to expose a
.name property instead which will contain the same strings as
DOMException.name.

I'm thinking we should do the same thing for IndexedDB too.

So having a central DOMError interface which we can reuse for all
places which expose asynchronous errors would be helpful. If
specifications want to add more information than what's defined by
DOM4, they can always extend the interface.

/ Jonas

Received on Tuesday, 4 October 2011 01:23:36 UTC