Re: [XHR] responseType "json"

On Sun, Dec 11, 2011 at 6:55 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Sun, 11 Dec 2011 06:10:26 +0100, Jarred Nicholls <jarred@sencha.com>
> wrote:
>
>> For legacy reasons, responseText and responseXML continue to work
>> together despite the responseType that is set.
>>
>
> This is false. responseType "text" allows access to responseText, but not
> responseXML. "document" allows access to responseXML, but not responseText.
>

I understand that's how you spec'ed it, but it's not how it's implemented
in IE nor WebKit for legacy purposes - which is what I meant in the above
statement.  Firefox (tested on 8) is the only one adhering to the spec as
you described above.  In WebKit and IE <=9, a responseType of "", "text",
or "document" means access to both responseXML and responseText.  I don't
know what IE10's behavior is yet.

I'll be fighting a battle soon to get WebKit to be 100% compliant with the
spec - and it's hard to convince others (harder than it should be) to
change when IE doesn't behave in the same manner.  The use case of error
reporting w/ contextual data (i.e. the bad payload) is still unsatisfied,
but it's not a common scenario.


>
> We made this exclusive to reduce memory usage. I hope that browsers will
> report the JSON errors to the console


The net response is always logged in the console, so this is satisfactory
for debugging purposes, just not realtime error handling.  I think an error
object would be good.  JSON errors reporting to the console will unlikely
be seen unless it is a defined exception being thrown, per spec.


> and I think at some point going forward we should probably introduce some
> kind of error object for XMLHttpRequest.


One of the inconsistencies with browsers (including IE and WebKit) are
how'when exceptions are being thrown when accessing different properties
(getResponseHeader, statusText, etc.).  The spec often says to fail
gracefully and return "null" or an empty string, etc., while IE and WebKit
tend to throw exceptions instead.  Perhaps an XHR error object would be
useful there.


>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>



-- 
................................................................

*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
<http://twitter.com/jarrednicholls>