<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - DOMError should be constructible as per the DOM4 specification"
href="https://bugs.webkit.org/show_bug.cgi?id=139173#c25">Comment # 25</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - DOMError should be constructible as per the DOM4 specification"
href="https://bugs.webkit.org/show_bug.cgi?id=139173">bug 139173</a>
from <span class="vcard"><a class="email" href="mailto:cdumez@apple.com" title="Chris Dumez <cdumez@apple.com>"> <span class="fn">Chris Dumez</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=139173#c24">comment #24</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=139173#c23">comment #23</a>)
> > (In reply to <a href="show_bug.cgi?id=139173#c22">comment #22</a>)
> > > (In reply to <a href="show_bug.cgi?id=139173#c21">comment #21</a>)
> > > > Dear All,
> > > >
> > > > DOMError can be removed from Webkit, since File APIs are not using it,
> > > > though as per FileReader Spec:<a href="http://dev.w3.org/2006/webapi/FileAPI/">http://dev.w3.org/2006/webapi/FileAPI/</a>, the
> > > > error attribute still uses the DOMError. Also in MDN link DOMError is still
> > > > used in File APIs:
> > > > <a href="https://developer.mozilla.org/en-US/docs/Web/API/FileReader.error">https://developer.mozilla.org/en-US/docs/Web/API/FileReader.error</a>
> > > >
> > > > 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
> (<a href="http://www.w3.org/TR/IndexedDB/">http://www.w3.org/TR/IndexedDB/</a>)
>
> The W3C recommendation for DOM4 (<a href="http://www.w3.org/TR/dom/">http://www.w3.org/TR/dom/</a>) still includes
> DOMError in an appendix. It warns to not use it, and instead refer to
> "Error" in WebIDL (<a href="http://www.w3.org/TR/WebIDL-1/">http://www.w3.org/TR/WebIDL-1/</a>)
>
> The previous working draft for DOM4
> (<a href="http://www.w3.org/TR/2015/PR-dom-20151006/">http://www.w3.org/TR/2015/PR-dom-20151006/</a>) 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
> (<a href="http://people.mozilla.org/~jorendorff/es6-draft.html#sec-error-objects">http://people.mozilla.org/~jorendorff/es6-draft.html#sec-error-objects</a>)
>
> 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.</span >
Sure, I don't have any issue with adding the message attribute to DOMError. My main concern was about starting to expose DOMError on the global object, considering it is legacy.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>