W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [XHR] responseType "json"

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 12 Dec 2011 09:28:56 -0500
Message-ID: <4EE60FA8.6010300@mit.edu>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT