The spec says to throw a DOMException instead.
Created attachment 175013 [details] Patch
My main worry here is causing compatibility problems by changing the exception number from 101 to 19 for network error. Have you doing anything to assess the compatibility risk from this change?
(In reply to comment #2) > My main worry here is causing compatibility problems by changing the exception number from 101 to 19 for network error. Have you doing anything to assess the compatibility risk from this change? The compat risk should be low because other browsers do not even have XMLHttpRequestException object and they have never had a code property with the value 101.
This looks quite dangerous to me, too. How did you assess compatibility impact for mobile content, Dashboard widgets, and other environments where WebKit is prevalent?
(In reply to comment #4) > This looks quite dangerous to me, too. > > How did you assess compatibility impact for mobile content, Dashboard widgets, and other environments where WebKit is prevalent? People don't rely on error codes for XHR exceptions. People use events and check the status property.
Is there any need to change this behavior in WebKit if no one relies on it? It's perplexing that anyone could consider removing this exception code after it being in the standard for years. Is there any reason for WebKit to track standards if they get changed on a whim despite successful implementation experience?
It simplifies the platform. Is removing cruft that nobody relies on not beneficial? I think it is. In this specific case, if we need to, we can keep the exception number for XHR network exceptions 101 without keeping the whole XMLHttpRequestException class, but it seems extremely unlikely to me that sites are depending on this.
(In reply to comment #6) > Is there any need to change this behavior in WebKit if no one relies on it? This is a philosophical question that I don't think we will ever agree on. I strongly believe that we should improve the platform where it is possible.
Comment on attachment 175013 [details] Patch Attachment 175013 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14905375 New failing tests: http/tests/xmlhttprequest/XMLHttpRequestException.html
Comment on attachment 175013 [details] Patch Attachment 175013 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14905394 New failing tests: http/tests/xmlhttprequest/XMLHttpRequestException.html
> I strongly believe that we should improve the platform where it is possible. Making the platform inconsistent with previous generation specs and unreliable benefits companies with large web development budgets who can maintain compatibility with a wide range of browser versions, at the expense of smaller competitors and users, as browsers gradually become incompatible with web sites outside of top 100 or so. It's just business, nothing philosophical.
FWIW, this was only in the spec in the 2007-2008 timeframe. It changed end of 2008 afaict. The whole concept of XMLHttpRequestException only lasted during 2007.
Created attachment 178073 [details] Patch
> The whole concept of XMLHttpRequestException only lasted during 2007. I think that this statement is misleading. XMLHttpRequestException is present in a lot of browsers in 2012. That should be enough of a reason to add it back.
(In reply to comment #14) > > The whole concept of XMLHttpRequestException only lasted during 2007. > > XMLHttpRequestException is present in a lot of browsers in 2012. I don't think WebKit alone counts as a lot of browsers. XMLHttpRequestException is not available in Firefox. XMLHttpRequestException is not available in Internet Explorer. XMLHttpRequestException is not available in Opera.
Comment on attachment 178073 [details] Patch Attachment 178073 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/15159837
> XMLHttpRequestException is not available in Firefox. > XMLHttpRequestException is not available in Internet Explorer. > XMLHttpRequestException is not available in Opera. This is not a very good way to count browsers for compatibility analysis. Counting engines is helpful to count independent implementations, which is useful to assess technical feasibility of widespread implementation.
Comment on attachment 178073 [details] Patch Attachment 178073 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/15185147
Comment on attachment 178073 [details] Patch Attachment 178073 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/15909636
Blink removed XMLHttpRequestException a while back (https://code.google.com/p/chromium/issues/detail?id=229395). We are now probably safe removing it as well?
(In reply to comment #20) > Blink removed XMLHttpRequestException a while back > (https://code.google.com/p/chromium/issues/detail?id=229395). > > We are now probably safe removing it as well? I vote yes.
Note that similarly, I already dropped support for the legacy EventException in Bug 149597 fairly recently.
<rdar://problem/24338476>
Created attachment 269822 [details] Patch
Comment on attachment 269822 [details] Patch r=me
Committed r195588: <http://trac.webkit.org/changeset/195588>