On 2012/09/12 21:02:42, jtamplin wrote:
On 2012/09/12 20:47:20, skybrian wrote:
> Hmm, I'm inclined to skip this patch for GWT 2.5. The typo fix at
least makes
it
> work on some browsers...
If I understand Thomas' test results, the getter works properly
everywhere -- it
is the existing setter which fails on FF11+. So, this patch doesn't
add
anything broken, but you can 't actually use any non-default response
type on
FF+ even with what is in trunk now.
That's right.
Let's sum up what's broken at each stage:
1. introduction of responseType (with a typo):
- throws in IE6 for anything but ResponseType.Default (because
Default is the empty string, the "if (xhr && responseType)" check is
false)
- should work everywhere else ('responsetype' treated as an expando;
verified in FF15), but "broken" as the provided value is not being used.
2. fixing the typo:
- same behavior for IE6
- Now breaks on Firefox which expects responseType to be set after a
call to open(); workaround: create with ResponseType.Default then use
JSNI to set the responseType after you've called open()
- works everywhere else (either the browser supports responseType, or
it treats it as an expando)
3. adding the getter:
- same situation as above, except now you can get the value (which
should be the one you passed to create(): we use an enum so you can only
pass the empty string or arraybuffer, and all browsers supporting
responseType support both values so they won't "sanitize" the passed
value to something else –e.g. Firefox silently ignoring "dummy"–)
I think we don't want to screw up the API just to deal with a
non-compliant
browser -- making a setter would require the callers to set it after
the fact
(and it seems like it would be a race condition if the reply comes
back before
you set it).
That "race condition" is handled by the spec: setting responseType would
throw if you try to set it after you called send().
There's a trade-off to make between just providing Java access to the
XHR, as a dummy JSO, or providing a higher-level API (but that's more
the role of the RequestBuilder, which BTW hasn't been updated with
responseType support).
To me, XHR falls on the former bucket: it should work like an XHR in JS,
with just a few tweaks to workaround browser bugs (the factory to make
it work on IE6, the onreadystatechange=nullFunction trick) without
changing the semantics.
It's already advertised as being a low-level API, so I'd rather add a
setter so that it can be used in all browsers (particularly including
Firefox) provided you call it "at the right time".
The create(ResponseType) factory method could either be kept in as an
convenience/short-hand, or we could remove it (it only shipped in
2.5.0-rc1 for now, and wasn't working as expected until a few days ago;
if it can help with internal Google code, we could deprecate it for RC2
and remove it for the final version)
Is there a FF bug for this?
Reported last December, no feedback so far.
https://bugzilla.mozilla.org/show_bug.cgi?id=707484
https://gwt-code-reviews.appspot.com/1830803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
