[Webkit-unassigned] [Bug 139173] DOMError should be constructible as per the DOM4 specification

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 9 10:25:36 PST 2015


https://bugs.webkit.org/show_bug.cgi?id=139173

Brady Eidson <beidson at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |beidson at apple.com

--- Comment #24 from Brady Eidson <beidson at apple.com> ---
(In reply to comment #23)
> (In reply to comment #22)
> > (In reply to comment #21)
> > > Dear  All,
> > > 
> > >       DOMError can be removed from Webkit, since File APIs are not using it,
> > > though as per FileReader Spec:http://dev.w3.org/2006/webapi/FileAPI/, the
> > > error attribute still uses the DOMError. Also in MDN link DOMError is still
> > > used in File APIs:
> > > https://developer.mozilla.org/en-US/docs/Web/API/FileReader.error
> > > 
> > > Thanks
> > 
> > We still use DOMError in WebKit (for e.g. MediaStream and IndexedDB API,
> > CSSFontFaceLoadEvent). It is likely that the corresponding specifications
> > are not using DOMError anymore so our implementations would have to be
> > updated first.
> 
> 
> Dear  Chris,
> 
>       Yes right, we need to update our implementations for other module to
> support using DOMError, may be later we can accept these changes, is it
> right?

DOMError is still used in the W3C recommendation for IndexedDB (http://www.w3.org/TR/IndexedDB/)

The W3C recommendation for DOM4 (http://www.w3.org/TR/dom/) still includes DOMError in an appendix. It warns to not use it, and instead refer to "Error" in WebIDL (http://www.w3.org/TR/WebIDL-1/)

The previous working draft for DOM4 (http://www.w3.org/TR/2015/PR-dom-20151006/) explains the real impetus behind that change - DOMError can't be removed because some specs still use it (Namely IndexedDB).

WebIDL defines "Error" as the set of all objects that can be used to represent an error, which correspond to the ECMAScript error objects (http://people.mozilla.org/~jorendorff/es6-draft.html#sec-error-objects)

ECMAScript error objects have a message property.

I have a few points for listing the current state of the specs WRT DOMError:
1 - DOMError is baked into the final IndexedDB spec, and therefore we can't remove it.
2 - But DOMError is strongly deprecated.
3 - DOMError's non-deprecated replacement is basically "an object representing an Error that has a message property"
4 - IndexedDB code sure would love to have custom messages in its DOMErrors instead of just a generic error code.

My personal takeaway from all of the above is that we *should* add the the message property to DOMError so it can better fulfill its purpose, but we should NOT add the constructor.

I still think the message part of this patch is relevant, and I would love to see it land soon.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151209/a12890ec/attachment.html>


More information about the webkit-unassigned mailing list