Bug 123457 - XHR.response is null when requesting empty file as arraybuffer
Summary: XHR.response is null when requesting empty file as arraybuffer
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Alexey Proskuryakov
URL: http://people.cs.umass.edu/~jvilk/emp...
Keywords: BlinkMergeCandidate
Depends on:
Blocks:
 
Reported: 2013-10-29 11:57 PDT by John Vilk
Modified: 2013-10-30 23:52 PDT (History)
5 users (show)

See Also:


Attachments
proposed fix (6.51 KB, patch)
2013-10-29 17:16 PDT, Alexey Proskuryakov
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Vilk 2013-10-29 11:57:20 PDT
Steps to reproduce:
1. Create an asynchronous XMLHttpRequest for an empty file with responseType set to 'arraybuffer'.
2. Send the request.
3. When the request finishes loading successfully (req.readyState is 4, req.status is 200), req.response will be set to NULL.

Expected behavior:
Since I requested an ArrayBuffer representation of an empty file and that request *succeeded*, req.response should be an ArrayBuffer of size 0.

Code:
window.addEventListener('load', function() {
  var req = new XMLHttpRequest();
  req.open('GET', './empty.txt', true);
  req.responseType = 'arraybuffer';
  req.onload = function(e) {
    if (req.readyState === 4 && req.status === 200) {
      // The request succeeded!
      // In non-WebKit browsers, req.response will be an ArrayBuffer of byteLength 0.
      // In WebKit browsers (Chrome/Safari), req.response will be NULL.
    }
  };
  req.send();
});

A live demo of this test code can be seen here:
http://people.cs.umass.edu/~jvilk/empty_xhr_bug.html

Firefox and Opera (Presto engine) both set response to a 0-length ArrayBuffer. I have yet to test IE10.
Comment 1 John Vilk 2013-10-29 11:59:08 PDT
Apologies for the irrelevant addEventListener call in my code snippet; I copypasta'd the snippet from the demo page, and forgot to remove it.
Comment 2 John Vilk 2013-10-29 12:13:02 PDT
Apologies for mentioning Chrome; I forgot about the Blink transition.

The Chrome 31 beta actually fixes this bug, but Safari 6.1 and Opera 17 still have the issue.
Comment 3 Alexey Proskuryakov 2013-10-29 16:49:40 PDT
Thank you for the report.

> The Chrome 31 beta actually fixes this bug

That's a useful pointer, we can save some time by simply taking the fix and not re-doing it.

https://chromium.googlesource.com/chromium/blink.git/+/aaeae38f24f53918cf66c1a16845777068d1e510
Comment 4 Alexey Proskuryakov 2013-10-29 17:16:05 PDT
Created attachment 215451 [details]
proposed fix

Code fix turned out to be non-mergeable, but I used their test (with some tweaks).
Comment 5 WebKit Commit Bot 2013-10-30 13:33:54 PDT
Comment on attachment 215451 [details]
proposed fix

Rejecting attachment 215451 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.appspot.com', '--bot-id=webkit-cq-03', 'apply-attachment', '--no-update', '--non-interactive', 215451, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
chanize/_urllib2_fork.py", line 332, in _call_chain
    result = func(*args)
  File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_urllib2_fork.py", line 1170, in https_open
    return self.do_open(conn_factory, req)
  File "/Volumes/Data/EWS/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_urllib2_fork.py", line 1118, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error [Errno 8] nodename nor servname provided, or not known>

Full output: http://webkit-queues.appspot.com/results/17088317
Comment 6 WebKit Commit Bot 2013-10-30 17:31:15 PDT
Comment on attachment 215451 [details]
proposed fix

Clearing flags on attachment: 215451

Committed r158333: <http://trac.webkit.org/changeset/158333>
Comment 7 WebKit Commit Bot 2013-10-30 17:31:17 PDT
All reviewed patches have been landed.  Closing bug.
Comment 8 Ryosuke Niwa 2013-10-30 18:46:17 PDT
Looks like this patch broke the following two XHR tests on Mavericks?

http/tests/xmlhttprequest/response-encoding.html
http/tests/xmlhttprequest/xmlhttprequest-overridemimetype-content-type-header.html

http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=http%2Ftests%2Fxmlhttprequest%2Fresponse-encoding.html%2Chttp%2Ftests%2Fxmlhttprequest%2Fxmlhttprequest-overridemimetype-content-type-header.html

e.g.
http://build.webkit.org/results/Apple%20Mavericks%20Release%20WK1%20(Tests)/r158333%20(267)/results.html
Comment 9 Alexey Proskuryakov 2013-10-30 23:52:51 PDT
Tracked as bug 123548 now.

The code change was fine, but the test uncovered an unrelated bug. Surprising that EWS didn't report this - it saw that the tests became "flaky". We should probably disable retries on EWS.