Able to reproduce the issue on windows 7,Linux Ubuntu 14.04 and Mac 10.12.2 using chrome version 56.0.2924.87 and canary 58.0.3000.4.
This is regression issue broken in M56. Please find the bisect information as below

Narrow Bisect::
Good :: 56.0.2922.0   ---   (build revision 432511)
Bad:: 56.0.2924.0  ---    (build revision 433059)

CHANGELOG URL:
===============  https://chromium.googlesource.com/chromium/src/+log/028c9afaa41a29d47e7e40202082b89a667c445f..cf848a6957fb402bdffeb5a2ce51e9f0cbbb98f2

Possible suspect::
https://chromium.googlesource.com/chromium/src/+/cf848a6957fb402bdffeb5a2ce51e9f0cbbb98f2

dmurph@ could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue.

Thanks,

I created a layouttest for this issue, attached (and put it in fast/files).

yhirano@, I believe your work might have surfaced this issue. I see this CL:
https://codereview.chromium.org/2342023002

I'm not sure when it was hooked up - but anyways, the code detects a file object at ComplexFormDataBytesConsumer::ComplexFormDataBytesConsumer, but the file length is -1 (which is what happens when creating a file as an object - the length isn't fetched until '.size' is called, as this costs a sync disk call).

I think this is never fetched, and we end up with an arraybuffer with 0 size.

Deleted: blob-reading-from-form-file.html 1.2 KB

blob-reading-from-form-file.html 1.2 KB View Download

Actually that might not be exactly the case of what's happening...

https://chromium.googlesource.com/chromium/src/+log/4793d9335b9ce611e2deb40863793fa785773200..3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a

My change is r421219, which is out of the bisect range (432511, 433059). dmurph@, what do you think about it?

I have assumed I can read a FormData by reading a blob containing all elements in the FormData. It looks it worked but is not working now.

I haven't fully debugged the situation, I just ended up far outside of blob-land and it looked like you had made recent changes there.

I think the problem is the file with the unknown size (-1, or UINT64_MAX), but I'm not sure. I will continue debugging to figure it out, and if I can't narrow it down at the end of the day I'll assign back to you. 

Possible bug #1: 
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/fetch/BlobBytesConsumer.cpp?q=BlobBytesConsumer&dr=CSs&l=55

the m_blobURL isn't being saved to a member variable ever - so it can't be revoked.

Possible  bug #2 :
Same spot, the given URL is never revoked when we're done reading the blob, which leaks that blob data. It is in cancel (which never works, as it's never saved), but that isn't called on a 'successful' read.

These both seem like real bugs - I should probably be included in reviews where blobs are used.

Alright, I found the bug. The blob is not constructed correctly, and reports an error of ERR_INVALID_CONSTRUCTION_ARGUMENTS. It's not reported correctly, as the this happens in the constructor of BlobReader, where it just doesn't set the handle.

So instead we should be calling ReportError, or at least setting the net error code.

But still - this request now returns a 404, and I'm not sure why that means the ending arraybuffer() is empty with a size of 0, but that's the status.

So it looks you're creating an illegal blob - which might be due to:
1. Creating a blob with multiple elements, where one is a file with unknown size, or
2. Creating a blob referencing another blob, where the referenced blob is a file with unknown size.

I think it's #2. It looks like we create 2 blobs, one to encompass all of the form elements (which is just a file w/ unknown size - valid), and then another blob referencing the first blob. Another solution here is to maybe special case that again in the blob system.
Here is the failure spot:
https://cs.chromium.org/chromium/src/storage/browser/blob/blob_storage_context.cc?q=blob_storage_context.cc&dr&l=239

I'll create a patch for better error reporting in BlobReader, and create a bug for the issues I saw above. Can you investigate the best way to solve this issue in the Fetch system? It might be good to just fetch the file size at some point - or maybe I can try to special case this in the Blob system.

Created issue for url bug here:
https://bugs.chromium.org/p/chromium/issues/detail?id=695250

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e80397e738255b07d17d508c77acc2a87966f614

commit e80397e738255b07d17d508c77acc2a87966f614
Author: dmurph <dmurph@chromium.org>
Date: Thu Feb 23 01:21:40 2017

[BlobStorage] Better net error reporting for pre-broken blobs

BUG= 688100 

Review-Url: https://codereview.chromium.org/2709213003
Cr-Commit-Position: refs/heads/master@{#452326}

[modify] https://crrev.com/e80397e738255b07d17d508c77acc2a87966f614/content/browser/blob_storage/blob_url_request_job_unittest.cc
[modify] https://crrev.com/e80397e738255b07d17d508c77acc2a87966f614/storage/browser/blob/blob_reader.cc
[modify] https://crrev.com/e80397e738255b07d17d508c77acc2a87966f614/storage/browser/blob/blob_url_request_job.cc

Thank four for the investigation. I'll try to read blobs manually and compose them in the renderer.

So it looks like a blob is created with 3 items:
1: a bytes item of 136 bytes.
2: a file item w/ unknown size (illegal to construct blob w/ file item of unknown size when it's not the only item)
3: a bytes item w/ 46 bytes.

So you'll need to do a fstat on that file.

I plan on adding a DCHECK on the renderer side when this happens after this is fixed, so it's easier to see this problem.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3dca0cfff95b9b9d8806184490be8b87f76af378

commit 3dca0cfff95b9b9d8806184490be8b87f76af378
Author: yhirano <yhirano@chromium.org>
Date: Thu Mar 23 11:07:51 2017

Add unknown file size handling in ComplexFormDataBytesConsumer

...to read data from a form data containing a file chosen via the file picker.

BUG= 688100 

Review-Url: https://codereview.chromium.org/2710033003
Cr-Commit-Position: refs/heads/master@{#459043}

[add] https://crrev.com/3dca0cfff95b9b9d8806184490be8b87f76af378/third_party/WebKit/LayoutTests/fast/files/blob-reading-from-form-file.html
[add] https://crrev.com/3dca0cfff95b9b9d8806184490be8b87f76af378/third_party/WebKit/LayoutTests/fast/filesystem/form-reading-from-file.html
[modify] https://crrev.com/3dca0cfff95b9b9d8806184490be8b87f76af378/third_party/WebKit/Source/modules/fetch/FormDataBytesConsumer.cpp

Sorry for the long delay, but I believe it's fixed.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d94af97739e56d4174dc320b16d36f6795f2622f

commit d94af97739e56d4174dc320b16d36f6795f2622f
Author: dmurph <dmurph@chromium.org>
Date: Thu Mar 30 20:49:38 2017

[BlobStorage] Enforcing renderer constraints to prevent broken blobs

R=pwnall, yhirano
BUG= 688100 

Review-Url: https://codereview.chromium.org/2717583003
Cr-Commit-Position: refs/heads/master@{#460867}

[modify] https://crrev.com/d94af97739e56d4174dc320b16d36f6795f2622f/third_party/WebKit/Source/core/fileapi/File.cpp
[modify] https://crrev.com/d94af97739e56d4174dc320b16d36f6795f2622f/third_party/WebKit/Source/core/fileapi/FileTest.cpp
[modify] https://crrev.com/d94af97739e56d4174dc320b16d36f6795f2622f/third_party/WebKit/Source/platform/blob/BlobData.cpp
[modify] https://crrev.com/d94af97739e56d4174dc320b16d36f6795f2622f/third_party/WebKit/Source/platform/blob/BlobData.h

Fixed by #19. Thanks!