Close remaining File API spec gaps in FileReader - #57745
Closed
Abbondanzo wants to merge 2 commits into
Closed
Conversation
…oad the correct commit data. Differential Revision: D113802292
Summary: Builds on [react#57692](react#57692), which fixed the `abort()` state machine and reset `result`/`error` at the start of each read via the `_startRead()` helper. A few gaps remain versus the [File API spec](https://w3c.github.io/FileAPI/): a read that starts while the reader is `LOADING` is silently superseded instead of throwing, `loadstart` is never dispatched, and `error` is a plain `Error` rather than a `DOMException`. This change: - throws an `InvalidStateError` `DOMException` when a read starts while the reader is `LOADING`, by extending the `_startRead()` helper - fires `loadstart` when a read begins - exposes `error` as a `DOMException` (`NotReadableError`), matching the spec typing No `progress` event is synthesized: `NativeFileReaderModule` resolves the whole payload in a single promise, so there is no incremental read to observe. The spec fires `progress` opportunistically as bytes stream in (it is not a required event), and emitting one post-completion `progress` with `loaded === total` would report data the reader never actually measured — a handler would also see `reader.result === null` at that point. The lifecycle is covered by `loadstart`/`load`/`error`/`abort`/`loadend`. The legacy `readystatechange` event is left untouched, and the deprecated `readAsBinaryString()` is out of scope. ## Changelog: [GENERAL] [FIXED] - Fire `loadstart`, throw `InvalidStateError` on overlapping reads, and expose `FileReader.error` as a `DOMException`. Differential Revision: D113819663
meta-cla
Bot
added
the
CLA Signed
|
@Abbondanzo has exported this pull request. If you are a Meta employee, you can view the originating Diff in D113819663. |
|
This pull request has been merged in 544141e. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Builds on #57692, which fixed the
abort()state machine and resetresult/errorat the start of each read via the_startRead()helper. A few gaps remain versus the File API spec: a read that starts while the reader isLOADINGis silently superseded instead of throwing,loadstartis never dispatched, anderroris a plainErrorrather than aDOMException.This change:
InvalidStateErrorDOMExceptionwhen a read starts while the reader isLOADING, by extending the_startRead()helperloadstartwhen a read beginserroras aDOMException(NotReadableError), matching the spec typingNo
progressevent is synthesized:NativeFileReaderModuleresolves the whole payload in a single promise, so there is no incremental read to observe. The spec firesprogressopportunistically as bytes stream in (it is not a required event), and emitting one post-completionprogresswithloaded === totalwould report data the reader never actually measured — a handler would also seereader.result === nullat that point. The lifecycle is covered byloadstart/load/error/abort/loadend. The legacyreadystatechangeevent is left untouched, and the deprecatedreadAsBinaryString()is out of scope.Changelog:
[GENERAL] [FIXED] - Fire
loadstart, throwInvalidStateErroron overlapping reads, and exposeFileReader.erroras aDOMException.Differential Revision: D113819663