[Webkit-unassigned] [Bug 49633] Add .responseType and .response to XMLHttpRequest

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=49633


Alexey Proskuryakov <ap at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|Other                       |All
         OS/Version|Mac OS X 10.5               |All
             Status|UNCONFIRMED                 |NEW
          Component|New Bugs                    |XML
     Ever Confirmed|0                           |1




--- Comment #14 from Alexey Proskuryakov <ap at webkit.org>  2010-11-20 14:12:47 PST ---
This looks really good to me. Not sure if we want more baking time for discussion, keeping at r? in case we do.

As for string vs. named type discussion - let's do whatever is required to get other browser vendors on board with the new API, this doesn't seem to be a major issue. I haven't been following e-mail discussion in enough detail to tell who had a very strong opinion on that.

+    else if (responseType == "blob") {
+#if ENABLE(XHR_RESPONSE_BLOB)
+        m_responseTypeCode = ResponseTypeBlob;
+#else
+        ec = SYNTAX_ERR;
+#endif

It would be cleaner to just let it fall through to default section.

+    case ResponseTypeBlob:
+        return "blob";

I'm somewhat surprised that this is not inside an #if (ditto for enum values in header). This is not a big deal - if this has made other code significantly more readable in your opinion, let's keep it.

-    bool asBlob() const { return m_asBlob; }
+    bool asBlob() const { return responseTypeCode() == ResponseTypeBlob; }

Our normal naming scheme is for asXXX() and toXXX() functions to return XXX objects.

+responseXML serialized
+<!DOCTYPE doc><doc>
+  <foo xmlns="foobar">One</foo> <x:bar xmlns:x="barfoo">Two</x:bar>
+  <d id="id3">Three</d>
+</doc>

There is a downside to making this test depend on minute details of XML serialization. E.g., it's likely to catch someone off guard when fixing bug 25206. 

I'd love to see tests for what happens when accessing .response when the load is only partially done, and in case the request has been aborted.

> Index: LayoutTests/fast/xmlhttprequest/resources/balls-of-the-orient.aif

We've got tons of resource files to request, why add another huge one? If you intend to use it for testing audio API later, then the location may not be so good.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.