Repository navigation
fix(core): TextDecoder decodes only the bytes of a typed array view - #11578
Merged
Merged
Conversation
|
View your CI Pipeline Execution ↗ for commit fe56a60
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
commit: |
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.
PR Checklist
What is the current behavior?
TextDecoder.decode()turns a typed array orDataViewintonew Uint8Array(input.buffer), which is the view's entire underlyingArrayBuffer. A view that covers only part of a buffer, such as asubarray(), aBufferslice, or a pooled buffer, therefore also decodes the bytes outside the view. That's what breakscborand libp2p decoding in #9941.What is the new behavior?
For views, the decoder reads exactly
byteOffset..byteOffset + byteLength. PlainArrayBufferinput and the existing type check don't change.The new spec
text/text-common.spec.tscoversArrayBuffer,subarrayandDataViewranges, a multi-byte round trip throughTextEncoder, and the non-buffer rejection. The two view-range cases fail without the fix. The full core suite passes (556 tests).Closes #9941.