1034009 - Progress event of FileReader API should be asyncronous

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Shian-Yow Wu [:swu]]

The FileReader API is asyncronous, but it sends progress event syncronously.
When reading a blob by readAsArrayBuffer(), if the reading is done quickly, it is possible that the load event handler been called before the readAsArrayBuffer() returns.

Comment 1

[Shian-Yow Wu [:swu]]

It seems we cannot fire all progress events asyncronously, the File API test case expects several events fired sync, such as:
const] 1650 INFO TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_fileapi.html | arrayBuffer loadstart should fire sync - got false, expected true
const] 1661 INFO TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_fileapi.html | abort should fire sync - got false, expected true
const] 1662 INFO TEST-UNEXPECTED-FAIL | /tests/content/base/test/test_fileapi.html | loadend should fire sync - got false, expected true

In W3C File API spec, it doesn't mention which events should be fired syncronously.
http://dev.w3.org/2006/webapi/FileAPI

Is there historical or implementation consideration that require some events(loadstart, abort, loadend) fired sync, or we should now make them all fired async?

Jonas, may I have comments from you?  Thank you.

Comment 2

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

"loadstart" should fire synchronously when readAsX is called.

"abort" and "loadend" should fire synchronously when abort() is called.

However "load" and "progress" should never fire from inside a readAsX. However simply changing the code that fires them to be asynchronous probably means that we could end up firing a "progress" when it doesn't make sense, such as after an "abort" event. This would also be bad.

Are you sure that "progress" can really fire from within readAsArrayBuffer()? Looking at the code, it looks like we only fire "progress" from an nsITimer callback. Such a callback should never fire from inside readAsArrayBuffer() unless we have code that spins the event loop, which hopefully we don't (if we do, we have much bigger problems).

It might definitely be the case that an nsITimer callback is *sheduled* from inside readAsArrayBuffer(), but all that happens when it's scheduled is that it's placed on the event queue. So it won't get called until we return to the event loop.

Comment 3

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.