Repository navigation
fix(mobile): move a lone pane's actions into the tab menu on touch screens - #835
Conversation
…reens A pane shown alone on a touch screen drew its own ellipsis over the chat, right under the header's, next to the tab's: three ellipses in one corner. The tab's touch menu now carries the open pane's actions and the lone pane's floating button is hidden while that menu button is on screen. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 6 minutes. View limit details
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Summary
Merge Risk: ⚪ Minimal · up to On touch screens, a lone pane's actions move into the tab menu, and split panes on wide touch screens keep their own menu. No concrete merge-blocking risk was identified in the supplied change. Pre-merge checks |
|
…ender Review finding (Codex, pre-merge): TabStrip renders before PaneCanvas, so its menu held the actions of the canvas's previous render; a snapshot that arrived while the sheet was up (another client closing the sibling pane) left Close pane deciding on the old pane count, skipping the last-pane confirmation. Each action now resolves itself against the canvas's current actions when it runs. No deterministic browser check: herdr's follow-up events re-render the strip before a tap can land on the stale items. The narrow-window and tablet menu checks assert the full ordered group of pane actions, as the phone check does. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
# Conflicts: # CHANGELOG.md
## Problem On a phone, a long press on the chat opened "Pane actions for …" instead of the phone's own text selection and copy. A touch long press fires `contextmenu`, and `PaneCanvas`'s capture handler took every contextmenu for the pane menu. ## Change - `PaneCanvas` ignores a contextmenu whose `pointerType` is `touch` or `pen` (or, where the event carries none, one that followed a touch/pen pointerdown on the frame), and does not prevent its default. Mouse right-click and macOS Control-click are unchanged. - Pane actions stay reachable on touch from the pane's ⋯ (and from the tab menu once #835 lands). ## Tests - New `scripts/touch-long-press-demo-regression.ts` (demo app, phone viewport): a touch contextmenu is not prevented and opens no pane menu; a mouse right-click still opens it. It fails without the fix. Added to `ci-browser.sh` (lane count 36 → 37 in `ci-browser.test.ts`). - `bun run check fast`, `tab-menu-regression`, `key-bar-hold-repeat-regression`, `terminal-arrows-clicks-regression` pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
## Change Release 0.4.8, from main at ca6db6e (20 PRs since v0.4.7: the 0.4.7 mobile walk-through fixes, two contributor PRs and the revived #793). - `package.json` and `herdr-plugin.toml`: 0.4.8. - CHANGELOG: `[Unreleased]` becomes `[0.4.8] - 2026-10-12`, with the compare links. Twelve entries that had no PR link get theirs (#835 #837 #838 #840 #842 #843 #844+#848 #845 #847 #849 #851 #852). A Maintenance line says the remote-PC runtime is now version 27. - `release-summaries.json`: 0.4.8 in en/ko/ja/zh/tr (3 new, 6 improved, 8 fixed). The Turkish lines are not checked by a native speaker. - `REMOTE_BUNDLE_VERSION` 26 -> 27: #836 adds the `pending-hold` server feature and #787 serves precompressed assets, so `remote-v27` is published before the app release. Every PR merged since v0.4.7 is linked in the section: #787 #788 #793 #835 #836 #837 #838 #839 #840 #841 #842 #843 #844 #845 #846 #847 #848 #849 #851 #852. ## Validation - `bun scripts/release-notes.ts 0.4.8` renders the summaries and the full changelog (116 lines). - `bun run check fast`: generated types, typecheck, build and 2800+ unit tests pass. ## Release After this merges and its CI on `main` passes: push `remote-v27`, wait for its release, then run the Release workflow with `0.4.8`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Conflicts: version 0.4.801; the classic tab strip and one-pane canvas kept beside upstream devswha#835's pane actions in the touch tab menu; the open latest work prop kept with devswha#788's immutable turn revisions. Upstream devswha#846 removed the header's plan button and its dialog: they stay as the default, and its plan in the background-task chip is Settings → Appearance → Plan in the message box, off (on under automation). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Problem
On a phone, opening a chat showed three ellipsis buttons around the top-right corner: the header's More, the active tab's touch menu, and the lone pane's own pane-actions button (always visible on touch since #747), which floated over the chat text right under the header's.
Change
PaneCanvasbuilds its pane actions with a shareditemsFor(pane)and publishes it through anactionsReffromApp.TabStrip's touch menu (opened from its ellipsis) now lists: the tab's panes (phone split), then the open pane's actions (rename, clear name, split, zoom, right-click passthrough, close), then the tab's actions. The desktop right-click tab menu is unchanged..tab-strip-menuis on screen, so where the strip is not drawn (short phone with one tab) the pane keeps its own button. Split panes on a wide touch screen keep their own menus.Tests
bun run check fastpasses.tab-menu-regression,mobile-tabs-regressionandui-regressionupdated for the merged menu and pass on an isolated herdr.🤖 Generated with Claude Code