On 2012/09/13 17:16:52, skybrian wrote:
Since this API is essentially just a wrapper around the JavaScript
object and
there's no place to stash the desired response type, adding the setter
and
deprecating create() with a response type seems like the way to go.
Done.
I wonder if we
https://gwt-code-reviews.appspot.com/1830803/diff/2003/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
File user/src/com/google/gwt/xhr/client/XMLHttpRequest.java (right):
https://gwt-code-reviews.appspot.com/1830803/diff/2003/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
File user/src/com/google/gwt/xhr/client/XMLHttpRequest.java (right):
Should we kill off the ResponseType enum and just take a String? It's
simpler, and this is low-level, after all.
- Brian
On Thu, Sep 13, 2012 at 11:08 AM, j...@jaet.org wrote:
https://gwt-code-reviews.appspot.com/1830803/diff/2003/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
File
I don't see any usages of XmlHttpRequest.ResponseType in Google code. We
could have constants instead of the enum.
https://gwt-code-reviews.appspot.com/1830803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2012/09/13 18:23:04, skybrian wrote:
I don't see any usages of XmlHttpRequest.ResponseType in Google code.
OK, so I'll remove the create(ResponseType).
We could have constants instead of the enum.
I kind of like the enums as in com.google.gwt.dom.client.Style (also
used in SafeStyles),
On 2012/09/13 20:22:43, tbroyer wrote:
I kind of like the enums as in com.google.gwt.dom.client.Style (also
used in
SafeStyles), but I'll make the setResponseType(String) public, and add
a
getResponseTypeString() to the enum.
Oops, I guess I should have responded. I'm fine with it either
LGTM
https://gwt-code-reviews.appspot.com/1830803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM
Did you test it? It probably needs testing on IE6 if GWT still
officially supports it, since I recall some weirdness about getting
exceptions if you referenced properties that didn't exist on native
objects that were exposed to JS.
https://gwt-code-reviews.appspot.com/1830803/
--
On 2012/09/12 14:32:37, jtamplin wrote:
Did you test it? It probably needs testing on IE6 if GWT still
officially
supports it, since I recall some weirdness about getting exceptions if
you
referenced properties that didn't exist on native objects that were
exposed to
JS.
Just ran the
On 2012/09/12 16:03:13, tbroyer wrote:
I'll try on IE7, IE8 and IE9 next (currently downloading the VMs from
the MSDN).
Results from https://browserlab.adobe.com
IE7, IE8 and IE9: works as an expando (no error; prints undefined,
arraybuffer, dummy)
Chrome 18 / Windows: throws on setting to
Hmm, I'm inclined to skip this patch for GWT 2.5. The typo fix at least
makes it work on some browsers...
https://gwt-code-reviews.appspot.com/1830803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
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
13 matches
Mail list logo
