New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Brownfield app crash after invalidating bridge and posting notification to NSNotificationCenter #42120
Comments
Hi @gabrieldonadel, thanks for the report. I was able to run the reproducer and to verify that happen. Now we can work on a solution.
What did you changed? How can I run the repro with the old arch? |
Hi @cipolleschi, thanks for checking this, to avoid having to always run |
thanks, I missed that line! xD |
Tested with the Old Arch, and it works without issues.
Out of curiosity, did you tested this setup also with bridgeless? How does it behave? |
Thanks for investigating this, I haven't tested with bridgeless yet but I can give it a shot later today |
@cipolleschi I gave Bridgeless mode a test and things are much better but this race condition still happens if the bundle is invalidated + restarted a bunch of times in sequence (not an issue in real-world scenarios). bridgeless.mp4I've updated the repo to support bridgeless and you can toggle it on by replacing this value -> |
# Why Closes ENG-10953 When navigating to home from dev-menu in an app dev-client with new arch enabled on iOS the app will crash due to `"AccessibilityManager is nil" due to the registry is nil` inside `RCTDeviceInfo`. This happens because when we invalidate the old bridge, create a new one, and then manually post an `RCTUserInterfaceStyleDidChangeNotification` notification, it gets received by an old instance of RCTDeviceInfo and then fails to find the module as the bridge is no longer valid. Removing the `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from `navigateToLauncher` fixes this racing condition issue and it doesn't seem to create any problems related to UserInterfaceStyle Created this issue on react-native core facebook/react-native#42120 # How - Remove `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from `navigateToLauncher` - Add minimum support to dark mode on fabric-tester # Test Plan https://github.com/expo/expo/assets/11707729/54a6b68e-8db8-4296-8c9b-29fa314cafb5 # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin).
# Why Closes ENG-10953 When navigating to home from dev-menu in an app dev-client with new arch enabled on iOS the app will crash due to `"AccessibilityManager is nil" due to the registry is nil` inside `RCTDeviceInfo`. This happens because when we invalidate the old bridge, create a new one, and then manually post an `RCTUserInterfaceStyleDidChangeNotification` notification, it gets received by an old instance of RCTDeviceInfo and then fails to find the module as the bridge is no longer valid. Removing the `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from `navigateToLauncher` fixes this racing condition issue and it doesn't seem to create any problems related to UserInterfaceStyle Created this issue on react-native core facebook/react-native#42120 # How - Remove `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from `navigateToLauncher` - Add minimum support to dark mode on fabric-tester # Test Plan https://github.com/expo/expo/assets/11707729/54a6b68e-8db8-4296-8c9b-29fa314cafb5 # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin).
# Why Closes ENG-10953 When navigating to home from dev-menu in an app dev-client with new arch enabled on iOS the app will crash due to `"AccessibilityManager is nil" due to the registry is nil` inside `RCTDeviceInfo`. This happens because when we invalidate the old bridge, create a new one, and then manually post an `RCTUserInterfaceStyleDidChangeNotification` notification, it gets received by an old instance of RCTDeviceInfo and then fails to find the module as the bridge is no longer valid. Removing the `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from `navigateToLauncher` fixes this racing condition issue and it doesn't seem to create any problems related to UserInterfaceStyle Created this issue on react-native core facebook/react-native#42120 # How - Remove `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from `navigateToLauncher` - Add minimum support to dark mode on fabric-tester # Test Plan https://github.com/expo/expo/assets/11707729/54a6b68e-8db8-4296-8c9b-29fa314cafb5 # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin).
We have a lead on this. We have not forgotten it! :D |
Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Reviewed By: RSNara Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Reviewed By: RSNara Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Reviewed By: RSNara Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Reviewed By: RSNara Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Reviewed By: RSNara Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Reviewed By: RSNara Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Reviewed By: RSNara Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Reviewed By: RSNara Differential Revision: D52912604
…#42396) Summary: Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Reviewed By: RSNara Differential Revision: D52912604
Summary: Pull Request resolved: #42396 Cmmunity reported [#42120](#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Reviewed By: RSNara Differential Revision: D52912604 fbshipit-source-id: 1727bcdef5393b1bd5a272e2143bc65456c2a389
Summary: Pull Request resolved: #42396 Cmmunity reported [#42120](#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating. Upon investigation, I realized that: 1. The RCTDeviceInfo module is never invalidated 2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up. This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers. ## Changelog: [iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge Reviewed By: RSNara Differential Revision: D52912604 fbshipit-source-id: 1727bcdef5393b1bd5a272e2143bc65456c2a389
…o module (#43737) Summary: Previous fix brings in #42396. Seems it's a mistake to re-add observer? So let's remove it and also not `invalidate` method not be called twice. ## Changelog: [IOS] [FIXED] - Remove invalidate observer instead of re-adding observer in DeviceInfo module Pull Request resolved: #43737 Test Plan: Fix for #42120 also works. Reviewed By: javache Differential Revision: D55692219 Pulled By: cipolleschi fbshipit-source-id: dba1ddc39a9f2611fc2b84fadf8c23827891379a
…o module (#43737) Summary: Previous fix brings in #42396. Seems it's a mistake to re-add observer? So let's remove it and also not `invalidate` method not be called twice. ## Changelog: [IOS] [FIXED] - Remove invalidate observer instead of re-adding observer in DeviceInfo module Pull Request resolved: #43737 Test Plan: Fix for #42120 also works. Reviewed By: javache Differential Revision: D55692219 Pulled By: cipolleschi fbshipit-source-id: dba1ddc39a9f2611fc2b84fadf8c23827891379a
Description
I believe there is some sort of bridge invalidation bug in react native 0.73 when using Brownfield apps with the new arch on.
When an app invalidates a bridge, then creates a new bridge, and manually posts an
RCTUserInterfaceStyleDidChangeNotification
notification, the app crashes with an error stating that `"AccessibilityManager is nil"`` due to the module registry being nil inside RCTDeviceInfo. Seems something related to the reinitialization of the turbo modules.This commit eb3d5a4b838ca7f632f02022e9be48402ca9d71f tried adding additional logging inside RCTDeviceInfo but that does not fix the issue and ended up causing the crash given the RCTAssert
Steps to reproduce
React Native Version
0.73.1
Affected Platforms
Runtime - iOS
Areas
TurboModule - The New Native Module System
Output of
npx react-native info
Stacktrace or Logs
Reproducer
https://github.com/gabrieldonadel/rn073BridgeInvalidation
Screenshots and Videos
292563657-75974536-da85-491c-967d-fc2b271a2808.mp4
The text was updated successfully, but these errors were encountered: