Bug 89034 – [Chromium] reading Blob includes non-existent file doesn't throw NotFound error

• Status: RESOLVED
• Resolution: WONTFIX
• Component: DOM

[Eric U.]

Chromium's Blob/BlobBuilder implementation now has a couple of behaviors that diverge from either the spec or the WebCore implementation or both.

1) [Likely spec divergence, but we match WebCore]: We don't snapshot a File at creation time.  We wait until the File is sliced or added to another Blob to capture its size and modification date.  This bug report is NOT for this spec divergence, but you have to know about this to understand that:
2) In Chromium, if you try to add a zero-length File or Blob [including a File with no backing file] to a Blob or BlobBuilder, we just silently drop it.  If it's a valid zero-length Blob or File, this isn't a problem.  However, if it's an invalid File [whose backing file is missing], we'd ideally generate an error somewhere along the line.  In the old code [before a couple of weeks ago] we'd just add it, and only find out at read time that there was a problem, and throw a read error.  This matched WebCore behavior.  When we fix #1, we'll find out at File creation time, and throw an error then.  In our current state, there's no error at all.

I don't think we need to fix this; fixing #1 will resolve the user-visible issues, since we'll then do no file IO at slice/add-Blob time and thus not notice an error or drop the File then.  But this bug is here to track the fact that we're currently showing the wrong behavior and failing silently.

There's a Chromium bug for #1 already: http://code.google.com/p/chromium/issues/detail?id=129325; we may need a WebKit bug as well.

[Kinuko Yasuda]

Steps to repro:
- create a File object (via <input type=file> etc)
- delete a File
- create a Blob including the file
- read the Blob

The bug is introduced by http://src.chromium.org/viewvc/chrome?view=rev&revision=138702
but is also partly due to WebCore's current implementation.

This can be tested with following tests (bug 87356) [you'll need to remove chrome-specific rebaseline results]:

fast/files/read-blob-async.html
fast/files/workers/worker-read-blob-async.html
fast/files/workers/worker-read-blob-sync.html

[Kinuko Yasuda]

> I don't think we need to fix this; fixing #1 will resolve the user-visible issues,

Note that we'll still have tiny incompatibility when we add an empty file and then the file gets removed before reading though it'll hardly be a real problem.

[Eric U.]

(In reply to comment #2)
> > I don't think we need to fix this; fixing #1 will resolve the user-visible issues,
> 
> Note that we'll still have tiny incompatibility when we add an empty file and then the file gets removed before reading though it'll hardly be a real problem.

I think we'll still match, actually.  If we snapshot before it's removed, we'll know it's zero length, and then not try to read from it.  I expect other ports to do the same--why try to read zero bytes?

[Kinuko Yasuda]

(In reply to comment #3)
> (In reply to comment #2)
> > > I don't think we need to fix this; fixing #1 will resolve the user-visible issues,
> > 
> > Note that we'll still have tiny incompatibility when we add an empty file and then the file gets removed before reading though it'll hardly be a real problem.
> 
> I think we'll still match, actually.  If we snapshot before it's removed, we'll know it's zero length, and then not try to read from it.  I expect other ports to do the same--why try to read zero bytes?

Yup, though it doesn't seem to be spec'ed?  Maybe we could file a w3c bug?  How other browsers work?

When one uploads multiple files including empty one, the server may get different set of files unless it's cleared?

[Stephen Chenney]

https://code.google.com/p/chromium/issues/detail?id=231345