Re: [w3c/FileAPI] Don't update FileReader's result until "LOAD" (#79)

And some tests to figure out the current behavior in https://github.com/w3c/web-platform-tests/pull/7494

In summary, currently Firefox seems to be the odd one out, with Chrome, Safari and Edge all having result available during progress events (at least during the last progress event; it's hard to come up with a cross-browser test that triggers multiple progress events). Firefox on the other hand seems to more closely follow the spec, with two exceptions: 1) when starting a new read it resets result to null, and 2) for readAsBinaryString Firefox actually does match the other three browsers and the result is available during the progress event. It's only for the other three read methods were it doesn't.

So maybe changing the spec to match Chrome/Safari/Edge rather than trying to change almost all the implementations to match the spec would make more sense...

(Edge does actually have slightly odd behavior: reader.result actually already contains the full result even during the loadstart event...)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/79#issuecomment-332342866