Add web-only floating RHP style

[BartekObudzinski]

Explanation of Change

On web wide layout the RHP now "floats": it is inset 12px from the top/right/bottom edges and gets rounded corners, a 1px border, and a shadow, while its background scrim uses a lighter color and lower opacity. The change is gated on Platform.OS === 'web' && !shouldUseNarrowLayout, so narrow layout and native keep the current full-bleed frame. RHP width is unchanged, so this is purely presentational and web-only.

Fixed Issues

$ Expensify#100811
PROPOSAL:

Tests

1. On desktop web (Chrome/Safari), open any RHP (e.g. Settings, or a chat's details panel). Verify it is inset from the top, right, and bottom viewport edges and has rounded corners, a thin border, and a drop shadow.
2. Verify the dimmed area behind the floating card is lighter than before, and that clicking it still closes the RHP.
3. Open an expense/report so the RHP widens (wide / super-wide). Verify the floating treatment holds at each width and during the open/close animation, with no dropped frames.
4. Stack a skinny RHP over a wide one (e.g. an expense's details). Verify the dimmed edges line up with the floating card and click-to-dismiss still works in the inset gap.
5. Narrow the browser window, then open on mWeb/native. Verify the RHP is full-bleed exactly as before (no inset, border, radius, or shadow).

• Verify that no errors appear in the JS console

Offline tests

These are presentational, web-only changes with no network dependency; offline behavior matches online.

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 a 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 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 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

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}

[BartekObudzinski]

not here