[$250] The “There’s a report awaiting action” UI is pushing other content out, leaving blank space displayed.

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.66-1
Reproducible in staging?: Y
Reproducible in production?: N (Debug option N/A)
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @quinthar @blimpich @brianlee-expensify
Slack conversation (hyperlinked to channel name): #Expensify Bugs #quality

Action Performed:

Precondition:
Have at least a report with GBR or RBR in LHN

1. Go to staging.new.expensify.com
2. Press CMD+D
3. Enable Debug mode
4. Navigate to LHN

Expected Result:

LHN menu displayed without any visual issues

Actual Result:

"There's a report awaiting action" UI is pushing LHN and blank space displayed

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @borys3kk

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022051335767738333893
• Upwork Job ID: 2051335767738333893
• Last Price Increase: 2026-05-04

[MelvinBot]

Proposal

What is the root cause of that problem?

The DebugTabView banner is rendered as a sibling before the tab bar container inside NavigationTabBar. On narrow/desktop layouts, the parent TabNavigatorBar uses a negative marginTop of -(bottomTabHeight + safeAreaPaddingBottom) via getTabBarNarrowStyle to overlay the tab bar on content with zero layout impact. This margin only accounts for the fixed 72px tab bar height — it does not account for the extra height added by DebugTabView. The uncompensated height pushes the LHN content and creates the visible blank space.

On wide layout, a similar issue occurs: DebugTabView is a sibling of leftNavigationTabBarContainer (which has height: '100%') inside an overflowHidden parent, causing layout displacement.

What changes do you think we should make in order to solve the problem?

Move the DebugTabView to use absolute positioning so it overlays on top of the tab bar instead of participating in the normal layout flow. In NavigationTabBar/index.tsx, render the DebugTabView inside a wrapper with position: 'absolute' anchored above the tab bar (e.g., bottom: 100%, left: 0, right: 0). This way it does not add any height to the tab bar container and will not affect the negative margin calculation or push any content.

What alternative solutions did you explore? (Optional)

An alternative would be to dynamically measure the DebugTabView height and add it to the negative marginTop in getTabBarNarrowStyle. However, this is fragile — it couples the margin calculation to a dynamic element's height and would need different handling for wide vs narrow layouts. Absolute positioning is simpler and avoids affecting the layout math entirely.

Investigation details

Key code locations:

• DebugTabView.tsx:168-185 — the banner component with p3 padding, flexRow layout, no absolute positioning
• NavigationTabBar/index.tsx:222-227 — narrow layout: DebugTabView rendered before the tab bar
• NavigationTabBar/index.tsx:136-143 — wide layout: DebugTabView rendered before the left nav tab bar
• getTabBarNarrowStyle — negative margin only accounts for bottomTabHeight (72px)
• TabNavigatorBar.tsx:115-119 — wide layout parent with overflowHidden

Data flow: Debug mode enabled → NavigationTabBar renders DebugTabView above tab bar → banner takes ~40-50px of layout space → narrow layout's fixed negative margin (-72px) doesn't compensate → content pushed / blank space appears.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @abzokhattab (External)

[MobileMage]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When debug mode is enabled and there is a report with GBR or RBR in the LHN, the "There's a report awaiting action" debug banner appears above the navigation tab bar but pushes LHN content upward, leaving blank space at the bottom of the list.

What is the root cause of that problem?

NavigationTabBar renders DebugTabView and the actual tab items as siblings in a React fragment. On narrow layout, TabNavigatorBar wraps the entire NavigationTabBar with a negative marginTop (via getTabBarNarrowStyle) that is sized to exactly bottomTabHeight + safeAreaPaddingBottom. This offset is hardcoded to the height of the tab items alone — it does not account for the additional height of the DebugTabView banner. When the banner is present, the overall fragment is taller than bottomTabHeight, but the negative margin only pulls up by the tab bar height, so the extra banner height remains as unreserved vertical space that displaces the LHN list content above it.

On wide layout the situation is similar: the <View style={styles.overflowHidden}> container in TabNavigatorBar grows to include both DebugTabView and leftNavigationTabBarContainer, but leftNavigationTabBarContainer has height: '100%' relative to its parent. Adding the banner as a sibling changes the flow of the containing column, pushing the tab container below its expected position and causing a layout gap.

App/src/libs/Navigation/AppNavigator/Navigators/TabNavigatorBar.tsx

Lines 100 to 112 in bdce78b

	if (shouldUseNarrowLayout) {
	// Negative marginTop overlays the tab bar on content (zero flex space) to prevent layout shifts.
	return (
	<View
	style={[StyleUtils.getTabBarNarrowStyle(safeAreaPaddingBottom), isHidden && styles.opacity0]}
	pointerEvents={isHidden ? 'none' : 'auto'}
	>
	<NavigationTabBar
	selectedTab={selectedTab}
	shouldShowFloatingButtons={!isHidden}
	/>
	</View>
	);

What changes do you think we should make in order to solve the problem?

The fix should ensure the debug banner does not contribute to the document flow in a way that displaces surrounding content. The cleanest approach is to render DebugTabView with position: 'absolute' and anchored to the top of its containing View (with a negative top offset equal to the banner's height, or using bottom: '100%'). This way the banner floats above the tab bar without adding any height to the tab bar's layout footprint, so the negative marginTop trick in TabNavigatorBar continues to work as intended for both the narrow and wide layouts.

Concretely, in DebugTabView.tsx, the root <View> should receive position: 'absolute', bottom: '100%' (or equivalently top with a negative offset computed from the banner's measured height using onLayout), and width: '100%' so it spans the full tab bar width and rises above it without occupying any space in the normal layout flow. The parent views in NavigationTabBar/index.tsx that currently wrap DebugTabView alongside the tab items may need overflow: 'visible' (narrow layout already has this via getTabBarNarrowStyle) to prevent clipping the absolutely-positioned banner.

App/src/components/Navigation/DebugTabView.tsx

Lines 168 to 186 in bdce78b

	return (
	<View
	testID="DebugTabView"
	style={[StyleUtils.getBackgroundColorStyle(theme.cardBG), styles.p3, styles.flexRow, styles.justifyContentBetween, styles.alignItemsCenter]}
	>
	<View style={[styles.flexRow, styles.gap2, styles.flex1, styles.alignItemsCenter]}>
	<Icon
	src={icons.DotIndicator}
	fill={indicator}
	/>
	{!!message && <Text style={[StyleUtils.getColorStyle(theme.text), styles.lh20]}>{translate(message)}</Text>}
	</View>
	<Button
	text={translate('common.view')}
	onPress={navigateTo}
	/>
	</View>
	);
	}

What alternative solutions did you explore? (Optional)

An alternative would be to make getTabBarNarrowStyle dynamically measure and account for the banner height by passing it as a parameter, adjusting the negative marginTop to -(bottomTabHeight + debugBannerHeight + safeAreaPaddingBottom). This would work on narrow layout but requires wiring onLayout measurements through multiple layers. The absolute-positioning approach is simpler, self-contained within DebugTabView, and naturally handles both narrow and wide layouts without touching the margin calculations.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022051335767738333893

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

DebugTabView is rendered as a normal-flow sibling of the actual navigation tab bar in both layouts.

On wide layout, NavigationTabBar renders DebugTabView before leftNavigationTabBarContainer:

App/src/components/Navigation/NavigationTabBar/index.tsx

Lines 135 to 147 in 29928fd

	if (!shouldUseNarrowLayout) {
	return (
	<>
	{shouldRenderDebugTabViewOnWideLayout && (
	<DebugTabView
	selectedTab={selectedTab}
	chatTabBrickRoad={chatTabBrickRoad}
	/>
	)}
	<View
	style={styles.leftNavigationTabBarContainer}
	testID="NavigationTabBar"
	>

The vertical tab bar itself has a fixed width but the debug banner does not:

App/src/styles/index.ts

Lines 719 to 725 in 29928fd

	leftNavigationTabBarContainer: {
	height: '100%',
	width: variables.navigationTabBarSize,
	justifyContent: 'space-between',
	borderRightWidth: 1,
	borderRightColor: theme.border,
	backgroundColor: theme.appBG,

Because the wide tab bar wrapper currently uses the rendered children to determine its layout footprint, the banner’s text/button row makes the whole tab bar area wider than the 64px rail, pushing the LHN to the right and leaving the blank space shown in the screenshot:

App/src/libs/Navigation/AppNavigator/Navigators/TabNavigatorBar.tsx

Lines 115 to 118 in 29928fd

	return (
	<View style={styles.overflowHidden}>
	<NavigationTabBar selectedTab={selectedTab} />
	</View>

On narrow layout, the same component is rendered before the bottom tab bar:

App/src/components/Navigation/NavigationTabBar/index.tsx

Lines 220 to 230 in 29928fd

	return (
	<>
	{!!isDebugModeEnabled && (
	<DebugTabView
	selectedTab={selectedTab}
	chatTabBrickRoad={chatTabBrickRoad}
	/>
	)}
	<View
	style={styles.navigationTabBarContainer}
	testID="NavigationTabBar"

The narrow wrapper intentionally offsets only bottomTabHeight + safeAreaPaddingBottom, so the extra DebugTabView height is not part of that layout calculation:

App/src/styles/utils/index.ts

Lines 2301 to 2306 in 29928fd

	getTabBarNarrowStyle: (safeAreaPaddingBottom: number): ViewStyle => ({
	overflow: 'visible',
	marginTop: -(variables.bottomTabHeight + safeAreaPaddingBottom),
	paddingBottom: safeAreaPaddingBottom,
	backgroundColor: theme.appBG,
	}),

What changes do you think we should make in order to solve the problem?

Render DebugTabView out of normal layout flow so it can still be visible in debug mode without changing the tab bar’s measured width or height.

Required changes:

• Add an optional style prop to DebugTabView and apply it to the root view.
• For wide layout, render the banner as position: absolute at top: 0, left: 0.
• For narrow layout, render the banner as position: absolute with bottom: '100%', left: 0, and right: 0, so it sits above the bottom tab bar.
• Make the tab bar wrapper position: relative so the absolute banner is anchored to the tab bar wrapper.
• Use overflowVisible for the wide tab bar wrapper so the absolute debug banner can paint outside the 64px rail without increasing the rail’s layout width.

Tests that should be added:

• Update the NavigationTabBar UI tests to verify DebugTabView is rendered with absolute positioning when debug mode is enabled.
• Add coverage for the wide-layout render path so the debug banner can render without changing the tab bar container’s normal layout footprint.

The existing proposals correctly identify that the banner must not participate in normal layout flow. The missing detail is that wide and narrow layouts need different anchors: bottom: '100%' is right for the bottom tab bar, but the wide vertical rail needs a top/left absolute anchor plus visible overflow on the wide wrapper. That is why this proposal keeps the same root-cause fix but makes the layout handling explicit for both tab bar orientations.

What alternative solutions did you explore? (Optional)

Fixed Demo:

Screencast.From.2026-05-05.00-13-27.mp4

[github-actions]

⚠️ @nabi-ebrahimi Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).