- 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