Repository navigation
fix(core): keep prototype-named keys in getTransferState - #71387
Open
rootvector2 wants to merge 2 commits into
Open
rootvector2 wants to merge 2 commits into
rootvector2 wants to merge 2 commits into
Conversation
`getTransferState` copies the restored transfer state into a plain object literal. Keys come verbatim from the serialized state, and `TransferState` already accepts keys such as `__proto__` and stores them in a null-prototype dictionary. Copying such an entry into a plain object assigns through the inherited `__proto__` setter instead: the entry disappears, the stored value becomes the result's prototype so its properties leak in as inherited values, and under `--disable-proto=throw` the copy throws. Reuse the existing `createDictionary` helper for the accumulator so these keys stay ordinary entries.
The transfer state backend merges the per-root `傻getTransferState` results into a plain object literal with `Object.assign`. A key such as `__proto__` assigns through the inherited setter, dropping the entry and reparenting the merged object. Use a null-prototype object as the merge target so the key is kept as an ordinary entry.
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.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Follow-up to #70266.
TransferStatenow keeps keys such as__proto__in a null-prototype dictionary and round-trips them throughtoJson, butgetTransferStateinpackages/core/src/render3/util/transfer_state_utils.ts(published asng.傻getTransferStatefor DevTools) still copies the restored entries into a plain object literal. For a serialized state like{"__proto__":{"cached":true},"constructor":"state"}the copy assigns through the inherited__proto__setter: the entry is missing from the returned object, the stored value becomes its prototype socachedshows up as an inherited property, and under Node's--disable-proto=throwthe copy throws. The DevTools backend then merges each root's result into another plain object withObject.assign, which drops the entry a second time.Issue Number: N/A
What is the new behavior?
getTransferStatebuilds its result with the existingcreateDictionaryhelper, and the DevTools merge target is a null-prototype object, so prototype-named keys stay ordinary entries all the way to the Transfer State tab.Does this PR introduce a breaking change?
Other information
The new spec in
transfer_state_spec.tsfails onmain(Object.keysis['constructor']and the prototype is the stored object) and passes with the change;//packages/core/test:testand the Chromium run of//devtools/projects/ng-devtools-backend/src/lib:client_event_subscribers_testare green locally.