656640 - DOM Files should DEFER_OPEN their streams

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Patch

This doesn't actually fix the TODO in the FileReader tests, because you can't construct a Blob for a non-existent file anyways ...

Still think we should take this though.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Doesn't that mean that the DOMFile might get a totally different file from when it was created?

Do we have any plans to do what WebKit does here and have the DOMFile go blank if the file is changed, say?

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to comment #2)
> Doesn't that mean that the DOMFile might get a totally different file from
> when it was created?

Yes, but I think that can happen now ...

> Do we have any plans to do what WebKit does here and have the DOMFile go
> blank if the file is changed, say?

We could, if we could tell that the file has changed.  Do you know how WebKit does this?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Nope.

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Jonas and I discussed making File object creation for <input type="file"> stat the file (so that we would have the size handy, among other things).  A size check might be good enough.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 531951 [details] [diff] [review]
Patch

Though would be great to have tests as discussed.

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/mozilla-central/rev/9776a5b8ccd9

The test will be much easier to write after the test refactoring in the BlobBuilder patch is landed, so setting in-testsuite? here.

Comment 8

[Shawn Wilsher :sdwilsh]

<3 for less Sync I/O on the GUI thread