fix: make toolbar responsive without narrow mode

[boyam01]

Fixes #3022

What changed

• remove Narrow mode completely: there is no synchronous holder-width read, ResizeObserver, or narrow/compact modifier class
• use a continuous CSS layout that keeps the 650 px content column centered when space permits and reserves a 58 px action rail when the holder gets thinner
• keep the Plus button on the content's leading side for both LTR and RTL holders, even when a wide viewport contains a 500 px editor
• preserve the existing mobile toolbar and bottom-sheet toolbox behavior
• avoid layout containment so viewport-fixed overlays keep their original containing block

The layout reacts directly to holder-size changes through CSS; it does not depend on a window resize event or a JavaScript breakpoint mode.

Reproduction

Before bc2dcb1, a 500 px holder in a 1000 px viewport put the Plus button at x=483 (the holder's right side) instead of its leading content edge at x=9. The new regression checks first failed on that geometry and now pass with the Plus button at the holder's leading edge and the block content after the action rail.

An RTL regression check also caught that this repository's PostCSS target resolves logical properties to physical LTR properties at build time. The final CSS therefore contains an explicit RTL mirror, and the compiled behavior is covered rather than inferred from source syntax.

Local verification

• focused Ui.cy.ts: 9/9 passed
• full yarn test:e2e: 356/356 passed across 40 specs
• yarn lint: exit 0 (existing repository warnings only; no errors)
• yarn lint:errors: exit 0
• yarn build: exit 0
• git diff --check: exit 0
• responsive-mode remnant scan: 0 matches

The full Cypress run completed without a process crash. Cypress retried one pre-existing utils/flipper.cy.ts case once; it passed on retry and is outside this sizing path.

[Copilot]

🟡 Changes recommended

Layout containment changes the containing block for existing fixed-position overlays, breaking viewport-based positioning.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Replaces JavaScript narrow-mode detection with responsive CSS container queries.

Changes:

• Removes the synchronous offsetWidth check.
• Adds container-query styling for toolbar, toolbox, and RTL layouts.
• Adds Cypress regression coverage for initialization and holder resizing.

File summaries

File	Description
src/components/modules/ui.ts	Removes narrow-mode detection and class.
src/styles/ui.css	Defines the container and responsive layout.
src/styles/toolbar.css	Repositions the plus button.
src/styles/toolbox.css	Aligns the narrow toolbox.
src/styles/rtl.css	Adds responsive RTL positioning.
src/styles/variables.css	Renames the toolbar spacing variable.
test/cypress/tests/modules/Ui.cy.ts	Adds responsive-layout regressions.

Review details

• Files reviewed: 7/7 changed files
• Comments generated: 1
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[neSpecc]

You're simply renamed "narrow" to "compact". Consider removing this mode at all and make the responsive layout instead. The Plus should always stay left, even on thin containers.

Note 1. Screen may be wide, but the container holding the editor is thin. Note 2. Make sure, the mobile version works as before.

[boyam01]

Got it, that makes a lot of sense.
I’ve removed the hardcoded compact mode and transitioned to a fully responsive layout. The plus button is now pinned to the left even in narrow containers, and I verified that the mobile view still behaves as expected.
Ready for another look whenever you have time!

[boyam01]

Addressed in bc2dcb1. I removed the mode entirely: there is no narrow/compact class, holder-width read, or ResizeObserver now.

The toolbar and block content use a continuous CSS layout. On a 1000 px screen, resizing the editor holder to 500 px keeps the Plus button at the holder's leading edge and leaves the content after the action rail. I also added the mirrored RTL case explicitly because this repo's PostCSS build resolves logical properties to physical LTR properties.

Mobile keeps the existing toolbar and bottom-sheet toolbox behavior, and the fixed viewport overlay regression remains covered. Local verification is green: focused 9/9 and full Cypress 356/356 across 40 specs, plus lint and production build.

Could you please take another look?

[boyam01]

@neSpecc The requested responsive-layout follow-up is available in bc2dcb1.

It removes the Narrow/Compact runtime mode, holder-width decision, and ResizeObserver. The regression coverage exercises a thin editor holder inside a wide viewport, the explicit RTL mirror, unchanged mobile toolbar/toolbox behavior, and viewport-fixed overlays.

Fresh local verification on this exact SHA with Node 18.20.1: focused Ui.cy.ts 9/9, test and production builds exited 0, lint exited 0 with no errors, and the branch is clean, mergeable, and current with next.

The prior review threads are now outdated, while the Cypress and ESLint workflow runs remain action_required pending upstream approval. Could a maintainer approve those workflows and re-review bc2dcb1 when available?

[codeCraft-Ritik]

Avoiding contain: layout makes complete sense for keeping viewport-fixed overlays attached to the correct containing block.

Could we also verify whether the new continuous CSS layout introduces other unintended containing blocks for position: fixed elements? Specifically, ensure no parent container in the continuous rail layout uses transform, filter, perspective, or backdrop-filter, as those will also hijack the fixed positioning context.

[boyam01]

@codeCraft-Ritik Following up on your containing-block question: the source/diff audit of bc2dcb1e2e594901bdd0f5159498b16986b2f8ff did not find a new fixed-position containing block introduced by this PR.

• The continuous rail changes adjust widths, margins, box sizing and offsets; they do not add transform, filter, perspective, backdrop-filter, contain or will-change declarations to the fixed elements' ancestor chains.
• The rectangle-selection overlay is appended directly to .codex-editor. The mobile popover overlay and panel are siblings under .ce-popover; the overlay is inserted alongside the panel. Neither chain gains one of the properties above.
• The existing popover transform animations are unchanged and apply to the panel itself, not a shared ancestor of the fixed panel and overlay.
• Existing regression coverage checks viewport-sized rectangle selection with a 500px-wide holder offset by 40px and mobile toolbox bounds within the viewport.

The previously pending CI checks have now all passed on this head: Cypress in Chrome, Edge and Firefox, plus ESLint.

Scope: this follow-up uses a static source audit and those existing CI results, not a new local browser run. It does not claim coverage for host applications adding their own containing-block properties to external ancestors, or mobile scroll-lock behavior. No additional code changes were made.

@neSpecc Could you re-review bc2dcb1 when available, including the removal of Narrow/Compact mode and the fixed-overlay evidence above?

[johanwestling]

Any progress on this one? The requested changes seem to have been addressed (at least somewhat). Anything else that needs more work? 🙂 @neSpecc

[Copilot]

🟡 Changes recommended

Holder-only resizing can leave the inline toolbar positioned using a stale cached content rectangle.

Get a fresh assessment by requesting another Copilot review.

Review details

• Files reviewed: 10/10 changed files
• Comments generated: 2
• Review effort level: Balanced

[neSpecc]

@boyam01 please, take a look

[boyam01]

@neSpecc Fixed in ee4c018.

Removed the persistent UI.contentRect cache. The getter now measures the current content bounds on demand, and InlineToolbar.move() reads the result once per positioning operation. No ResizeObserver, holder-width mode, or additional resize listener is introduced.

Added four regressions: LTR and RTL, each shrinking the holder from 700px to 350px and expanding it from 350px to 700px. Each case opens the toolbar first, closes it, changes only the holder width, then reopens it and checks the actual right edge against the current content column. The viewport stays fixed throughout. All four fail against 48ee794 without the fix and pass with it.

Local verification with Node 18.20.1 / Cypress 13.13.3 / headless Electron 118:

• Focused InlineToolbar + Ui specs: 19/19 passed, retries disabled.
• Full Cypress suite: 367/367 passed across 40 specs; the existing Flipper test used one configured retry.
• Source and test lint: no errors; changed test file: no warnings.
• Test/production builds and git diff --check: passed.

The maintainer's version/changelog changes are preserved. This fixes positioning on reopening; it does not add live repositioning while a toolbar remains open. The new upstream CI run is separate from these local results.

Current upstream CI status: both Cypress and ESLint are action_required with zero jobs started. Could a maintainer approve these workflow runs? They have not run or passed on this new head yet.