Landscape mWeb experiments

[GCyganek]

Explanation of Change

Improves mWeb phone landscape layout: floating pill tab bar, main tab headers scroll away with content, report header collapses on scroll with a floating back button, compact header/compose chrome, and headers/tabs hide while the soft keyboard is open.

Fixed Issues

$ #94042
PROPOSAL: N/A

Tests

• Verify that no errors appear in the JS console

Offline tests

N/A

QA Steps

Same as tests

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If the PR adds or modifies the UI:
  • I asked an AI agent to review the changes for accessibility issues and addressed its findings.
  • I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
  • I verified all new/changed elements have meaningful accessible names and roles.
  • I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[GCyganek]

@Expensify/design could you take a look at my experiments to make the mWeb landscape mode more usable? I mainly focused on two biggest issues here:

1. not showing focused input when keyboard opens (usually caused by fixed top and bottom elements that I need to hide somehow when keyboard opens)
2. very little vertical space to show scrollable main content

I tested many different things and only left these that seem to work the best or at least have some potential. I also focused on not affecting other platforms and portrait mode, as well as performance and complexity of the code in the used solutions. I used iOS Safari and Chrome, and Android Chrome for testing

This PR is not meant to be reviewed in the current state in terms of code, I opened it to show you what I was able to achieve in current state with the lowest impact on the app possible and to discuss what we want to keep and what we do not want. All ideas and opinions on the ones I implemented here are welcome.

cc: @mountiny for visibility.

I especially wanted to avoid adding mechanisms that would result in big changes in the code only for mWeb landscape to work better as I feel like we need to keep balance here and not end up in a situation where we have a lot of new code that needs to be maintained only for mWeb landscape mode which is not used that often, to say it gently.

Additionally, while I tested many different popular apps and their mWeb landscape versions working on this, I feel that it's hardly ever solid and, in some cases, not even as usable as our landscape mode currently without the changes on this PR.

Full list of the visible changes:

1. Navigation tab bar and floating buttons

• Full-width bottom tab bar replaced by a compact pill in the bottom-left corner.
• FAB moves to bottom-right corner, camera button stacked above it (although I'm thinking we could make it more compact than it looks now)
• Content extends to bottom edge under the pill. Lists get bottom padding so the last row can scroll clear of it. Taps beside the pill reach content underneath.
• Floating nav bar, FAB and camera button fade out while keyboard is open, back when it closes - to make sure it does not get pushed above keyboard which in most of the cases would cover the focused input which we want to prioritze when focused

2. Main screens

• Headers scroll away with content instead of staying pinned on main screens available in the bottom nav

3. Chat report screen

• Report header shorter: 72 to 48px.
• Compose row shorter: no fixed minimum footer height, gap between last message and composer removed.
• Header collapses when scrolling toward newest messages, returns when scrolling up into history.
• Floating round back button (top-left) fades in as header collapses.
• Header collapses while keyboard open, floating back button hidden in that state. Header returns on close unless scrolling had already hidden it.

4. Create expense screen

• Tabs row hides with the header when text input focused (amount, description, merchant fields)
• Docked confirm button scrolls with the fields while keyboard open, docks again on close.

5. Other

• Hiding headers when keyboard opens to make sure focused fields are visible on the narrowed screen
• Headers shorter (72->48px) to have more vertical space to show more content

Please, take into consideration that not everything works 100% on this PR, for example not all screens with inputs work well when keyboard opens (focused inputs may be covered by something with open keyboard), I focused on the main and most used screens.

My demos:

chrome Android

screen-20261001-160827-1790863640952.mp4.2.mp4

and worst case scenario for me - iOS Safari with multiple tabs open (so we have browser chrome and tabs bar taking vertical space):

ScreenRecording_10-01-2026.16-12-13_1.1.mp4

[shawnborton]

Love where a lot of this is going! For the tabs, just a heads up that we are going to implement new native tabs soon, in case that is helpful. We might want to see what options we have for native tabs now in these modes, perhaps even having the tabs go away on scroll, etc etc.

[shawnborton]

The fixed header scrolling away feels really nice too.