fix(admin): the item editor modal cannot be closed on a phone #314

New Issue

2026-09-06T07:35:02-05:00

bermudalamb commented

2026-09-06 07:35:02 -05:00

Reported from a phone against the build stamped Sep 6, 07:17 AM: opening an item leaves no way to close it. The buttons cannot be reached by scrolling.

Mechanism

frontend/src/admin/Admin.tsx:351 renders the item editor with a fixed pixel width:

<Modal ... destroyOnHidden width={720}>

antd treats width as a fixed pixel value and does not make it responsive. On a phone viewport of roughly 390–410 CSS pixels the modal is still laid out at 720px, so:

The footer's OK and Cancel are right-aligned inside 720px, putting them off-screen to the right.
The ✕ in the modal's top-right corner is off-screen for the same reason, which is why there is no way out at all rather than merely an awkward one.
antd sets overflow: hidden on document.body while a modal is open, so the page behind cannot be scrolled either.

The result is a genuine dead end: the only escape is the browser's back button or closing the tab.

The modal body compounds it — MDEditor with height={220} and preview="live" renders editor and preview side by side, which needs width this viewport does not have, and an Upload with listType="picture-card" sits below it.

Not limited to that one modal

Every admin overlay hardcodes a width, and none of them adapt:

File	Overlay	Width
`Admin.tsx:351`	Item editor (Add/Edit Item)	720
`Admin.tsx:458`	Preview drawer	420
`Customers.tsx:440`	Customer detail	640
`Customers.tsx:429`	(modal)	480
`Categories.tsx:239`, `Tags.tsx:122`	Category / tag editors	default

720 is the one that produces a true dead end, but 640 and 480 also overflow a phone.

Proposed fix

Handle it once in frontend/src/styles.css rather than editing every call site. The file already carries responsive rules for the site header, filter bar and inventory filters, each with a comment explaining the narrow-screen behaviour, so this follows the pattern already established there — and it fixes Modal.confirm in the review queue too, which has no call site to edit.

Below a phone breakpoint:

Cap the modal at the viewport width instead of its declared pixel width.
Give the modal body a max-height with overflow-y: auto, so a tall body scrolls inside the modal and the footer stays put rather than being pushed out of reach.
Let drawers take the full width.

Verification

The fix is a layout change and cannot be proven by the unit suite. It needs checking on a real phone, or in a browser's device emulation at 390×844, against each overlay in the table above:

Open Add Item and Edit Item — ✕, Cancel and OK all reachable without horizontal scrolling.
Scroll the modal body to the Upload control and back; the footer must stay visible.
Open a customer's detail from the Customers tab.
In the review queue, press Publish on an item whose price is unconfirmed and confirm the Modal.confirm dialog's buttons are reachable.
Open the preview drawer from the inventory table.

Worth deciding separately

MDEditor's preview="live" splits the pane in two. Even with the modal sized correctly, a side-by-side markdown editor and preview at ~390px is cramped. Switching to preview="edit" below the breakpoint would help, but it is a behaviour change rather than a layout fix and is not included here — the dead end is the bug worth fixing immediately.

Impact

Admin-only, so no customer sees it, but it makes the admin unusable from a phone for the item editor — which is the surface reached from the intake and upload-link notification emails, so a phone is a likely place to open it.

Reported from a phone against the build stamped `Sep 6, 07:17 AM`: opening an item leaves no way to close it. The buttons cannot be reached by scrolling. ## Mechanism `frontend/src/admin/Admin.tsx:351` renders the item editor with a **fixed pixel width**: ```jsx <Modal ... destroyOnHidden width={720}> ``` antd treats `width` as a fixed pixel value and does not make it responsive. On a phone viewport of roughly 390–410 CSS pixels the modal is still laid out at 720px, so: - The footer's **OK and Cancel are right-aligned inside 720px**, putting them off-screen to the right. - The **✕ in the modal's top-right corner is off-screen for the same reason**, which is why there is no way out at all rather than merely an awkward one. - antd sets `overflow: hidden` on `document.body` while a modal is open, so the page behind cannot be scrolled either. The result is a genuine dead end: the only escape is the browser's back button or closing the tab. The modal body compounds it — `MDEditor` with `height={220}` and `preview="live"` renders editor and preview side by side, which needs width this viewport does not have, and an `Upload` with `listType="picture-card"` sits below it. ## Not limited to that one modal Every admin overlay hardcodes a width, and none of them adapt: | File | Overlay | Width | | --- | --- | --- | | `Admin.tsx:351` | Item editor (Add/Edit Item) | **720** | | `Admin.tsx:458` | Preview drawer | 420 | | `Customers.tsx:440` | Customer detail | 640 | | `Customers.tsx:429` | (modal) | 480 | | `Categories.tsx:239`, `Tags.tsx:122` | Category / tag editors | default | 720 is the one that produces a true dead end, but 640 and 480 also overflow a phone. ## Proposed fix Handle it once in `frontend/src/styles.css` rather than editing every call site. The file already carries responsive rules for the site header, filter bar and inventory filters, each with a comment explaining the narrow-screen behaviour, so this follows the pattern already established there — and it fixes `Modal.confirm` in the review queue too, which has no call site to edit. Below a phone breakpoint: - Cap the modal at the viewport width instead of its declared pixel width. - Give the modal body a `max-height` with `overflow-y: auto`, so a tall body scrolls **inside** the modal and the footer stays put rather than being pushed out of reach. - Let drawers take the full width. ## Verification The fix is a layout change and cannot be proven by the unit suite. It needs checking on a real phone, or in a browser's device emulation at 390×844, against each overlay in the table above: 1. Open Add Item and Edit Item — ✕, Cancel and OK all reachable without horizontal scrolling. 2. Scroll the modal body to the Upload control and back; the footer must stay visible. 3. Open a customer's detail from the Customers tab. 4. In the review queue, press Publish on an item whose price is unconfirmed and confirm the `Modal.confirm` dialog's buttons are reachable. 5. Open the preview drawer from the inventory table. ## Worth deciding separately `MDEditor`'s `preview="live"` splits the pane in two. Even with the modal sized correctly, a side-by-side markdown editor and preview at ~390px is cramped. Switching to `preview="edit"` below the breakpoint would help, but it is a behaviour change rather than a layout fix and is **not** included here — the dead end is the bug worth fixing immediately. ## Impact Admin-only, so no customer sees it, but it makes the admin unusable from a phone for the item editor — which is the surface reached from the intake and upload-link notification emails, so a phone is a likely place to open it.

bermudalamb referenced this issue from a commit

2026-09-06 10:03:54 -05:00

fix(admin): keep a modal's controls on screen on a phone (#314)

bermudalamb referenced a pull request that will close this issue

2026-09-06 10:04:22 -05:00

fix(admin): keep a modal's controls on screen on a phone (#314) #316

bermudalamb closed this issue

2026-09-06 10:04:31 -05:00

bermudalamb referenced this issue from a commit

2026-09-06 10:04:32 -05:00

Merge pull request 'fix(admin): keep a modal's controls on screen on a phone (#314)' (#316) from bugfix/314-admin-modal-unclosable-on-phone into main

Sign in to join this conversation.