mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
Nick Gerleman
c9c5651108
Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/41614 Fixes https://github.com/facebook/react-native/issues/41545 SafeAreaView works by adding padding in order to shift content out of the safe area. This may change the layout dimensions of the SafeAreaView, in turn effecting its safe area insets. This can cause layout results to change, which in turn changes the inset value. Because of this, there is a tolerance, where safe area inset changes do not trigger a new update. Yoga is instructed to round layout dimensions to the closest physical pixel, so a very small difference in layout may result being off by about a pixel. Right now the tolerance is exactly one physical pixel, and if there is FP error here, we may not pass the test, and start oscillating with different layout values. After changing affected ShadowNode order to always be root-first, the first call to set the frame of the `SafeAreaView` happens when a non-zero-sized RootView is present, which I think may lead to a safe area inset update communicated that wasn't before? Or other cosmic butterflies. Layout rounds to one physical pixel in difference, and our tolerance is `0.00001` dips off (not helped that 1/3 screen scale cannot be represented as decimal, even without FP error). This adds a small tolerance beyond just the pixel boundary, matching the logic in Fabric, which seems to resolve the issue. Changelog: [iOS][Fixed] - FP Tolerance in iOS Paper SafeAreaView debouncing Reviewed By: philIip Differential Revision: D51539091 fbshipit-source-id: 88bddc38c7cd8d93feef5f12da64b124af22f46d