fix: paste (Cmd-V) inside app window + long replies scroll fully on desktop - #358
Merged
Merged
Conversation
1612bf0 made the composer position:fixed at the viewport bottom on EVERY size to solve a mobile gesture-bar problem, and had .content reserve room for it with padding-bottom: calc(var(--input-h) + 16px). On the desktop window (Chrome tab and the native WKWebView, both loading :8090/) that reservation did not hold at the end of the scroll range in WebKit, so the last ~60px of any reply longer than the viewport sat behind the composer and was unreachable — you had to zoom out to read the end of a reply. Scope the fixed-composer treatment to the touch/mobile media query, where it is needed, and let the composer be a normal flex child on desktop again (its pre-1612bf0 behaviour): .content flex:1 then sizes to the leftover space and scrolls the whole reply into view. Mobile layout unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The native app never installed an NSApp.mainMenu, only a status-bar item menu. Without a main-menu Edit menu carrying the standard clipboard key-equivalents, macOS had nowhere to dispatch Cmd-V (etc.) so paste silently failed in the dashboard's WKWebView — it only worked in a real browser because the browser ships its own Edit menu. Install a minimal main menu (App + Edit) at launch. The Edit items use the first-responder selectors (paste:/copy:/cut:/selectAll:/undo:/redo:) with a nil target, so the keystroke walks the responder chain to the focused WKWebView and the clipboard works in-app exactly as in a browser. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two faults on the native app / desktop window, both reported live.
1. Cmd-V (and C/X/A/Z) did nothing inside the app chat
The native app installed only a status-bar menu, never an
NSApp.mainMenu. macOS routes the clipboard shortcuts through the main menu's Edit items; with no Edit menu they had nowhere to dispatch, so paste silently failed in the WKWebView. Worked in Chrome only because the browser ships its own Edit menu.Fix: install a minimal main menu (App + Edit) at launch; Edit items use the first-responder selectors with a nil target so the keystroke reaches the focused webview. (
codec_launcher.swift)2. Long chat replies couldn't be scrolled to the end (Chrome + app)
1612bf0made the composerposition:fixedon every size and had.contentreserve space withpadding-bottom: calc(var(--input-h)+16px). On the desktop window that reservation didn't hold at the end of the scroll range in WebKit — the last ~60px of any reply taller than the viewport sat behind the composer, unreachable (zooming out was the only way to read it). Both surfaces load:8090/so both broke.Fix: scope the fixed-composer + padding reservation to the touch/mobile media query; desktop gets the composer back as a normal flex child (pre-1612bf0 behaviour) so
.contentsizes to the leftover space and scrolls fully. Mobile layout unchanged. (codec_dashboard.html)Verified the scroll mechanism in an isolated WebKit repro: last line reachable with the fix, unreachable without.
codec_dashboard.htmlis served fresh per request, so it goes live on next reload with no dashboard restart; the paste fix ships with the next app build.🤖 Generated with Claude Code