Keep FileReader in DONE state after abort - #57692
Closed
fallintoplace wants to merge 1 commit into
Closed
Conversation
fallintoplace
force-pushed
the
fix-filereader-abort-state
branch
from
July 25, 2026 20:26
beb7b66 to
71067af
Compare
Abbondanzo
reviewed
Jul 27, 2026
|
@Abbondanzo has imported this pull request. If you are a Meta employee, you can view this in D113802292. |
fallintoplace
force-pushed
the
fix-filereader-abort-state
branch
from
July 27, 2026 18:55
71067af to
23dca56
Compare
|
@Abbondanzo merged this pull request in e92816c. |
meta-codesync Bot
pushed a commit
that referenced
this pull request
Jul 29, 2026
Summary: Pull Request resolved: #57745 Builds on [#57692](#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`. Reviewed By: christophpurrer Differential Revision: D113819663 fbshipit-source-id: c7c37b3b578d825cdccf73840b2c0742b6a4eaf9
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
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:
Before #57375, reads never entered
LOADING, so the active abort path was effectively unreachable. Now that reads useLOADING, that path calls_reset()before and after transitioning toDONE, leaving the reader inEMPTYafterabort()returns.This differs from the File API abort algorithm, which keeps an active reader in
DONE. The final reset also overwrites a replacement read started by anaborthandler, and that new read clears the shared_abortedflag before the canceled native promise settles.This change:
DONEwith a null resultloadendif the abort handler starts another readChangelog:
[GENERAL] [FIXED] - Keep
FileReaderin the correct state after aborting a read.Test Plan:
yarn jest packages/react-native/Libraries/Blob/__tests__/FileReader-test.js --runInBand./node_modules/.bin/prettier --check packages/react-native/Libraries/Blob/FileReader.js packages/react-native/Libraries/Blob/__tests__/FileReader-test.js./node_modules/.bin/eslint --max-warnings 0 packages/react-native/Libraries/Blob/FileReader.js packages/react-native/Libraries/Blob/__tests__/FileReader-test.jsyarn flow-check