root/fusion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(planning): the add-comment trigger sat below the fold — the sheet outgrew its floating host (#3242)

Browse Source 
Fixes the red `main`: `planning-browser-e2e.test.ts > places the sole
contextual comment trigger by viewport in embedded and modal Planning`.

**Unclaimed and not a flake.** `check-file-claimed` reported UNCLAIMED,
it is not in the quarantine ledger, it reproduced locally and
deterministically, and it failed identically across three consecutive
Full Suite runs. Quarantine would have been the wrong instrument — that
rule is for flakes, and appeasing a consistent failure buries a real
regression.

## Root cause

`PlanningModeModal.css` sizes dialog Planning as a **full-viewport
sheet**:

```css
.planning-modal:not(.planning-modal--embedded) {
  height: 100dvh;
  min-height: 100dvh;   /* ← beats max-height: 100% */
  max-height: 100%;
}
```

That was correct until the modal branch moved **inside
`FloatingWindow`** (`FNXC:ModalTouchGeometry 2026-07-26-14:10`). The
floating host's body is shorter than the viewport — it sits below a
title bar — so the rule now asks the sheet to be *taller than the box
containing it*. `min-height` wins over `max-height`, so the sheet cannot
shrink to its host and overflows.

Measured by walking the ancestor chain at 768×900:

```
BUTTON.btn                 top=928 h=36        ← 28px past the fold
DIV.planning-actions       top=919 h=101
DIV.modal                  h=900               ← forced to full viewport height
DIV.floating-window__body  h=763  sh=900       ← host is 763 tall, content is 900
DIV.floating-window        h=765
```

The "Add comment to selection" control needed a scroll to reach —
exactly what the placement case exists to prevent.

## The fix

A scoped override under `.floating-window`, rather than editing the
sheet rule, so Planning rendered **outside** a floating host keeps its
full-viewport sizing:

```css
.floating-window .planning-modal:not(.planning-modal--embedded) {
  height: 100%;
  min-height: 0;
}
```

## Surface enumeration

Embedded Planning was **never affected** — it is excluded from the sheet
rule, and all four embedded viewports passed throughout. The failure was
modal-only, at every modal viewport (768, 769, 1024, 1280 — it fails
fast at the first).

**No new test.** The existing placement case already asserts this
invariant across **4 viewports × 2 presentations = 8 combinations**,
which is the surface enumeration for this affordance. It was red; it is
now green. Adding a narrower repro-only test would be the anti-pattern
the Fix-the-Invariant rule names.

## A disproven hypothesis, recorded

`min-height: 0` on `.planning-plan-review > .planning-plan-pane` — the
canonical flex-overflow fix, and a pattern used 10+ times in this very
file — **does not fix it**. Measured, not assumed. The overflow is one
level up, at the sheet/host boundary. Noted so the next reader does not
repeat the experiment.

## Verification

```
fix applied      Tests  5 passed (5)
fix reverted     Tests  1 failed | 4 passed (5)     ← the test genuinely holds this fix
fix restored     Tests  5 passed (5)
```

Neighbours green: **57 tests across 8 suites** (mobile
footer/bottom-space/pan-containment, terminal keyboard layout,
task-detail tablet width, mission planning modals mobile, mobile
planning input font size, task-detail floating geometry) plus **9**
planning e2e.

Changeset included (`patch`, category `fix`) — this is user-visible
dashboard behaviour.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
gsxdsm
2026-07-31 13:44:25 -07:00
committed by GitHub
parent f31a716a2a
commit efd8454b6c
2 changed files with 29 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
.changeset/planning-modal-floating-window-height.md Normal file
View File

@@ -0,0 +1,7 @@
---
"@runfusion/fusion": patch
---
summary: Fix the Planning "Add comment to selection" button sitting below the fold in the Planning window.
category: fix
dev: The modal branch moved inside `FloatingWindow` (2026-07-26) but `PlanningModeModal.css` still sized the sheet as a full-viewport sheet; `min-height: 100dvh` beat `max-height: 100%`, so it overflowed its shorter host body. Scoped override under `.floating-window`.

22
packages/dashboard/app/components/PlanningModeModal.css
View File

@@ -2561,6 +2561,28 @@ mobile and desktop offer the same View task / Return to sessions choices.
border-radius: 0; border-radius: 0;
} }
/*
FNXC:PlanningMode 2026-07-31-20:33:
THE SHEET IS NO LONGER THE VIEWPORT. The rule above sizes dialog Planning as a full-viewport
sheet, which was true until the modal branch moved inside `FloatingWindow`
(`FNXC:ModalTouchGeometry 2026-07-26-14:10`). Its host body is shorter than the viewport — it sits
below a title bar — so `min-height: 100dvh` now asks the sheet to be TALLER than the box it lives
in. `min-height` beats `max-height: 100%`, so the sheet cannot shrink to its host and simply
overflows.
Measured at 768x900: host body 763px tall, sheet forced to 900px, and the plan action rail
carrying "Add comment to selection" landed at top=928 — 28px past the fold. The control was
unreachable without scrolling, which is the one thing `planning-browser-e2e`'s placement case
exists to prevent. Embedded Planning was never affected: it is excluded from the rule above.
Scoped to the floating host rather than editing the rule above, so a Planning sheet rendered
outside `FloatingWindow` keeps its full-viewport sizing.
*/
.floating-window .planning-modal:not(.planning-modal--embedded) {
height: 100%;
min-height: 0;
}
.planning-error { .planning-error {
margin: var(--space-lg) var(--space-lg) 0; margin: var(--space-lg) var(--space-lg) 0;
} }