fix: restore selection should consider the window of the container #30951
+64
−9
Conversation
This file contains 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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Hi @ling1726! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at [email protected]. Thanks! |
|
I'm not sure how to test child windows in Jest, would appreciate any guidance from maintainers |
Comment on lines
60
to
63
| let win = window; | ||
| let element = getActiveElement(); | ||
| if (containerInfo?.ownerDocument?.defaultView) { | ||
| win = containerInfo.ownerDocument.defaultView | ||
| } |
There was a problem hiding this comment.
Note that we try to minimize optional chaining in the runtime because of how it expands when transpiled, and this case does it twice. Maybe:
let win = containerInfo?.ownerDocument?.defaultView ?? window;
packages/shared/ReactVersion.js
Outdated
| // at runtime. We should instead inject the version number as part of the build | ||
| // process, and use the ReactVersions.js module as the single source of truth. | ||
| export default '19.0.0'; | ||
| export default '19.0.0-rc-d6cb4e77-20240911'; |
|
If |
|
Here's a similar test: |
|
@josephsavona @rickhanlonii I've added a test in e545af8 please take a look 🙏🙏
|
|
Comparing: d3d4d3a...37e1b28 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
josephsavona
approved these changes
Sep 13, 2024
|
Thanks for the PR! |
github-actions bot
pushed a commit
that referenced
this pull request
Sep 13, 2024
…30951) ## Summary Fixes #30864 Before this PR the active elemen was always taken from the global `window`. This is incorrect if the renderer is in one window rendering into a container element in another window. The changes in this PR adds another code branch to use a `defaultView` of the container element if it exists so that `restoreSelection` after a commit will actually restore to the correct window. ## How did you test this change? I patched these changes to the repro repo in the linked issue #39864 https://github.com/ling1726/react-child-window-focus-repro/blob/master/patches/react-dom%2B18.3.1.patch. I followed the same repro steps in the linked issue and and could not repro the reported problem. Attaching screen recordings below: Before  After  DiffTrain build for [d9c4920](d9c4920)
This was referenced Sep 16, 2024
mofeiZ
added a commit
to mofeiZ/react
that referenced
this pull request
Sep 17, 2024
Rewrite `containerInfo?.ownerDocument?.defaultView ?? window` to instead use a ternary. This changes the compilation output (see [bundle changes from facebook#30951]). ```js // compilation of containerInfo?.ownerDocument?.defaultView ?? window var $jscomp$optchain$tmpm1756096108$1, $jscomp$nullish$tmp0; containerInfo = null != ($jscomp$nullish$tmp0 = null == containerInfo ? void 0 : null == ($jscomp$optchain$tmpm1756096108$1 = containerInfo.ownerDocument) ? void 0 : $jscomp$optchain$tmpm1756096108$1.defaultView) ? $jscomp$nullish$tmp0 : window; // compilation of ternary expression containerInfo = null != containerInfo && null != containerInfo.ownerDocument && null != containerInfo.ownerDocument.defaultView ? containerInfo.ownerDocument.defaultView : window; ``` This also reduces the number of no-op bundle syncs for Meta. Note that Closure compiler's `jscomp$optchain$tmp<HASH>` identifiers change when we rebuild (likely due to version changes). See [workflow](https://github.com/facebook/react/actions/runs/10891164281/job/30221518374) for a PR that was synced despite making no changes to the runtime.
eps1lon
pushed a commit
to vercel/next.js
that referenced
this pull request
Sep 18, 2024
**breaking change for canary users: Bumps peer dependency of React from `19.0.0-rc-206df66e-20240912` to `19.0.0-rc-a99d8e8d-20240916`** [diff facebook/react@206df66e...a99d8e8d](facebook/react@206df66...a99d8e8) <details> <summary>React upstream changes</summary> - facebook/react#30977 - facebook/react#30971 - facebook/react#30922 - facebook/react#30917 - facebook/react#30902 - facebook/react#30912 - facebook/react#30970 - facebook/react#30969 - facebook/react#30967 - facebook/react#30966 - facebook/react#30960 - facebook/react#30968 - facebook/react#30961 - facebook/react#28255 - facebook/react#30957 - facebook/react#30958 - facebook/react#30959 - facebook/react#30951 - facebook/react#30954 - facebook/react#30920 - facebook/react#30942 </details>
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
Fixes #30864
Before this PR the active elemen was always taken from the global
window. This is incorrect if the renderer is in one window rendering into a container element in another window. The changes in this PR adds another code branch to use adefaultViewof the container element if it exists so thatrestoreSelectionafter a commit will actually restore to the correct window.How did you test this change?
I patched these changes to the repro repo in the linked issue #39864 https://github.com/ling1726/react-child-window-focus-repro/blob/master/patches/react-dom%2B18.3.1.patch.
I followed the same repro steps in the linked issue and and could not repro the reported problem. Attaching screen recordings below:
Before
After
