fix(Android, Stack): Prefer consuming the top inset from DecorView

[t0maboro]

Description

The top inset from DecorView is currently used in both Screen and ScreenDummyLayoutHelper to manually apply layout adjustments. To ensure consistent behavior between Screen and Toolbar, we should preferably handle the top inset here. Relying on unhandledInsets may be unreliable, as they could already have been consumed earlier in the layout process.

Fixes: #3499

Changes

• Added logic for preferring top inset from DecorView.

Test code and steps to reproduce

I'm not able to reproduce this issue on our side, so I'm basing on the information from: #3499 (comment)
Additionally, I ensured that it causes no regression in Test3006, for which these changes were initially made.

Checklist

• Included code example that can be used to test this change
• Ensured that CI passes

[kkafar]

I don't approve this change right now for at least few reasons.

First - we don't have a valid reproduction, so it's really hard to tell what is the root cause of the issue -> blindly working around it introduces a hard to maintain code into our codebase. We should insist on having reproduction here.

Second - we should avoid using insets directly from window / decor, exactly for this reason -> if someone consumes the insets & sets the padding above us, we will apply the padding erroneously for the second time. This will most likely also break nested stacks scenarios. So I believe now that this is not really a fix, rather a workaround for this particular issue.

Third - likely the bug comes, because somebody (some component, maybe even one of ours) consumes the insets and does not apply correct padding and this is where we should look for the fix.

[faljabi]

Just to help here, I used claude code to help find the culprit that may help you identify the issue. Find the details below:

Root Cause Analysis: The regression was introduced by PR #3240 which changed how CustomToolbar retrieves window insets. The Breaking Change: In CustomToolbar.kt:116-129, the toolbar now uses unhandledInsets from super.onApplyWindowInsets(insets) instead of rootWindowInsets. Why It Fails: In edge-to-edge mode (enforced on Android SDK 35+), parent views in the hierarchy consume window insets before they reach the toolbar. By the time CustomToolbar.onApplyWindowInsets() is called, the top system bar inset has already been consumed, resulting in zero top padding. Affected Scenarios:
Apps using edge-to-edge mode (via react-native-edge-to-edge or native implementation)
Modal presentations (presentation: 'modal' or 'containedModal')
Any screen where insets are consumed by parent views before reaching the toolbar
Evidence:
Version 4.18.0: Works correctly because resolveInsetsOrZero() defaults to using rootWindowInsets
Version 4.19.0: Broken because it only uses consumed/unhandled insets passed down the hierarchy
The Solution: PR #3500 correctly addresses this by preferring DecorView insets as the source of truth for top insets, which are never consumed regardless of the view hierarchy.

Hope this helps.

[andreialecu]

I can confirm we also encountered the issue in #3499, and this PR fixes it (applied via patch-package).

[esimkowitz]

I can confirm the bug in 4.19.0 and the patch suggested resolves it.

@kkafar I understand your reasoning, but this manifests as a regression, given a lot of libraries with non-rendering providers (i.e. react-native-keyboard-controller) eat insets provided from parents. We can go chase these in a bunch of repos, but maintaining backwards compatibility is really important. I agree that your logic is the "correct" approach and other libraries should be aligning to this, however I would recommend documenting this as a breaking change, with a new option that maintains the old behavior for at least a few releases with a deprecation notice and a CTA to fix behavior in other projects.

I'm willing to prepare an updated version of this fix with a feature gate and deprecation notice if you are willing to sign off on it.

[kkafar]

@t0maboro Is this PR still relevant in the light of recent changes?

[t0maboro]

I think it's fine to close this one, falling back to decor view insets was added here:

react-native-screens/android/src/main/java/com/swmansion/rnscreens/CustomToolbar.kt

Line 125 in 52f93e6

val topInset = getDecorViewTopInset(decorView)