- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 12 Dec 2011 09:28:56 -0500
- To: public-webapps@w3.org
On 12/12/11 8:12 AM, Jarred Nicholls wrote:
> I started an initiative to bring XHR in WebKit up-to-spec (see
> https://bugs.webkit.org/show_bug.cgi?id=54162) and got a lot of push
> back.
That seems to be about a different issue than responseType, right?
I just tried the following testcase:
<script>
var xhr = new XMLHttpRequest();
xhr.open("GET", window.location, false);
xhr.responseType = "document"
xhr.send();
try { alert(xhr.responseText); } catch (e) { alert(e); }
try { alert(xhr.responseXML); } catch (e) { alert(e); }
xhr.open("GET", window.location, false);
xhr.responseType = "text"
xhr.send();
try { alert(xhr.responseText); } catch (e) { alert(e); }
try { alert(xhr.responseXML); } catch (e) { alert(e); }
</script>
Gecko behavior seems to be per spec: the attempt to get responseText
fails on the first XHR, and the attempt to get responseXML fails on the
second XHR.
WebKit (tested Chrome dev channel and Safari 5.1.1 behavior) seems to be
partially per spec: the attempt to get responseText throws for the first
XHR, but the attempt to get the responseXML succeeds for the second XHR.
That sort of makes sense in terms of how I recall WebKit implementing
feeding data to their parser in XHR, if the implementation of
responseType just wasn't very careful.
Given that WebKit already implements the right behavior when
responseType = "document", it sounds like the only bug on their end here
is really responseType = "text" handling, right? It'd definitely be
good to just fix that...
-Boris
Received on Monday, 12 December 2011 14:36:54 UTC