Status bar inconsistently updates color when modal opens on Android

[sidorchukandrew]

Before submitting a new issue

• I tested using the latest version of the library, as the bug might be already fixed.
• I tested using a supported version of react native.
• I checked for possible duplicate issues, with possible answers.

Bug summary

When you use the <SystemBars /> component or imperatively use pushStackEntry and popStackEntry inside a React Native modal, the status bar style is inconsistently applied. Sometimes it'll update to the correct color, other times it doesn't.

I troubleshooted and followed all the way down to the Android layer and can confirm that the value is getting passed to isAppearanceLightStatusBars here.

This is happening on new and old arch.

Note: I know that edge to edge functionality is now built into React Native 81, and my reproducible example is using 81 with react-native-edge-to-edge, but this is also present in RN 79.

Screen_Recording_20250903_132658_EdgeToEdge.mp4

Library version

1.7.0

Environment info

System:
  OS: macOS 15.5
  CPU: (10) arm64 Apple M1 Pro
  Memory: 93.88 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.18.0
    path: ~/.nvm/versions/node/v20.18.0/bin/node
  Yarn:
    version: 1.22.22
    path: ~/.nvm/versions/node/v20.18.0/bin/yarn
  npm:
    version: 10.8.2
    path: ~/.nvm/versions/node/v20.18.0/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.16.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.5
      - iOS 18.5
      - macOS 15.5
      - tvOS 18.5
      - visionOS 2.5
      - watchOS 11.5
  Android SDK: Not Found
IDEs:
  Android Studio: 2025.1 AI-251.26094.121.2512.13930704
  Xcode:
    version: 16.4/16F6
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.12
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 20.0.0
    wanted: 20.0.0
  react:
    installed: 19.1.0
    wanted: 19.1.0
  react-native:
    installed: 0.81.1
    wanted: 0.81.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: Not found
  newArchEnabled: false

Steps to reproduce

1. Add <SystemBars style="light" /> to your app.
2. Add a RN modal
3. In the modal add <SystemBars style="dark" />
4. Open and close the modal a few times. You should see that sometimes it does not update the color of the status bar.

Reproducible sample code

https://github.com/sidorchukandrew/rn-edge-to-edge-repro

[zoontek]

This is a well-known issue in React Native: Modal are actually android Dialog instances. This means that their Window system bars theme cannot be updated from libraries.

What's happening here?

1. When you open a Modal, its content render.
2. When SystemBars is rendered, a native call updates the native bar style.
3. Modal are syncing the system bars theme with the MainActivity one (see https://github.com/facebook/react-native/blob/v0.81.1/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/modal/ReactModalHostView.kt#L412)

Here, as both calls are made at the same time, there's a race condition. That's also the reason why, when you update the StatusBar / SystemBars theme when a modal is opened, it has no effect, except when createNewDialog is true, as it will force a re-sync.

How to fix this?

For that, we would need some sort of Modal listener, store the android Window instances references and apply the system bars config to every instance of them. Unfortunately, there's no way to do this yet (see facebook/react-native#45534)

[zoontek]

If you want to avoid this issue for now, try updating the SystemBars configuration imperatively before calling the setState used to make the Modal visible. This reduces the likelihood of a race condition occurring.

[sidorchukandrew]

This makes a ton of sense. I tried doing a setTimeout in the modal with the imperative methods and it didn't update at all. Your suggestion makes sense as well. I think in the same thought process, when the modal dismounts, we should imperatively call to pop the stack entry.

From the PR you linked, it also sounds like the RN team is open to figuring this out? The issue was closed due to inactivity.

[sidorchukandrew]

What can we do to get this on the radar of the RN team? Should we reopen an issue?

[zoontek]

@sidorchukandrew Yes, I have to ping them again and see if we could get that merged. I think re-opening an issue + linking the stale PR is a great start. I will see if I can contact them directly too.

[zoontek]

If you use something like this, you should be fine (it's not perfect, sure, but we cannot really do better for the moment):

SystemBars.pushStackEntry({ /* … */ });
setTimeout(() => setModalVisible(true), 100)

[sidorchukandrew]

Thank you for the suggestion and explaining what the issue about the race-condition! Feel free to close this comment (or keep it open to track its status?).

[zoontek]

@sidorchukandrew Let's keep it open so people can find it easily until it's fixed upstream.