Remove XMLHttpRequestException

• Component: DOM
• Status: RESOLVED FIXED

[Erik Arvidsson]

The spec says to throw a DOMException instead.

[Erik Arvidsson]

Created attachment 175013 [details]
Patch

[Adam Barth]

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?

[Erik Arvidsson]

(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.

[Alexey Proskuryakov]

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?

[Erik Arvidsson]

(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.

[Alexey Proskuryakov]

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?

[Ojan Vafai]

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.

[Erik Arvidsson]

(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.

[Build Bot]

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

[Build Bot]

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

[Alexey Proskuryakov]

> 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.

[Anne van Kesteren]

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.

[Erik Arvidsson]

Created attachment 178073 [details]
Patch

[Alexey Proskuryakov]

> 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.

[Erik Arvidsson]

(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.

[Build Bot]

Comment on attachment 178073 [details]
Patch

Attachment 178073 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/15159837

[Alexey Proskuryakov]

> 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.

[Build Bot]

Comment on attachment 178073 [details]
Patch

Attachment 178073 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/15185147

[Build Bot]

Comment on attachment 178073 [details]
Patch

Attachment 178073 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://queues.webkit.org/results/15909636

[youenn fablet]

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?

[Chris Dumez]

(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.

[Chris Dumez]

Note that similarly, I already dropped support for the legacy EventException in Bug 149597 fairly recently.

[Radar WebKit Bug Importer]

<rdar://problem/24338476>

[Daniel Bates]

Created attachment 269822 [details]
Patch

[Chris Dumez]

Comment on attachment 269822 [details]
Patch

r=me

[Daniel Bates]

Committed r195588: <http://trac.webkit.org/changeset/195588>