Skip to content

weakly hold key window for KVO frame listener#50231

Closed
philIip wants to merge 1 commit into
facebook:mainfrom
philIip:export-D71667722
Closed

weakly hold key window for KVO frame listener#50231
philIip wants to merge 1 commit into
facebook:mainfrom
philIip:export-D71667722

Conversation

@philIip
Copy link
Copy Markdown
Contributor

@philIip philIip commented Mar 24, 2025

Summary:
Changelog: [Internal]

RCTDeviceInfo uses KVO to listen to frame changes in the application's keyWindow. On initialization, it reads the global keyWindow and adds itself as a listener. When RCTDeviceInfo is cleaned up, it reads the global keyWindow again, and removes itself as an observer.

However, this makes an assumption that the keyWindow is always the same. This is not always true - for example, when a UIAlert is presented, the OS creates a new temporary keyWindow to host the alert in order to make sure it is the first responder. If the cleanup is called then, the app will crash because there is no RCTDeviceInfo observing it. Another example is the LogBox, which also temporarily creates a new keyWindow.

The fix is simple, we can capture a reference to the application's keyWindow on initialization, but make sure it is weakly held as the keyWindow is usually managed by iOS. Then, when we remove the listener, it is always guaranteed it is the window that we are observing.

Reviewed By: javache, cipolleschi, realsoelynn

Differential Revision: D71667722

Summary:
Changelog: [Internal]

RCTDeviceInfo uses KVO to listen to frame changes in the application's keyWindow. On initialization, it reads the global keyWindow and adds itself as a listener. When RCTDeviceInfo is cleaned up, it reads the global keyWindow again, and removes itself as an observer.

However, this makes an assumption that the keyWindow is always the same. This is not always true - for example, when a UIAlert is presented, the OS creates a new temporary keyWindow to host the alert in order to make sure it is the first responder. If the cleanup is called then, the app will crash because there is no RCTDeviceInfo observing it. Another example is the LogBox, which also temporarily creates a new keyWindow.

The fix is simple, we can capture a reference to the application's keyWindow on initialization, but make sure it is weakly held as the keyWindow is usually managed by iOS. Then, when we remove the listener, it is always guaranteed it is the window that we are observing.

Reviewed By: javache, cipolleschi, realsoelynn

Differential Revision: D71667722
@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Mar 24, 2025
@facebook-github-bot
Copy link
Copy Markdown
Contributor

This pull request was exported from Phabricator. Differential Revision: D71667722

@facebook-github-bot
Copy link
Copy Markdown
Contributor

This pull request has been merged in 90fce63.

@facebook-github-bot facebook-github-bot added the Merged This PR has been merged. label Mar 24, 2025
@react-native-bot
Copy link
Copy Markdown
Collaborator

This pull request was successfully merged by @philIip in 90fce63

When will my fix make it into a release? | How to file a pick request?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported Merged This PR has been merged. p: Facebook Partner: Facebook Partner

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants