* Fix terminal keys (arrows, Ctrl+N/P) swallowed after opening browser After a browser panel is shown, SwiftUI's internal focus system activates and its _NSHostingView starts consuming arrow keys and other non-Command key events via performKeyEquivalent, preventing them from reaching the terminal's keyDown handler. Fix: In the NSWindow performKeyEquivalent swizzle, when GhosttyNSView is the first responder and the event has no Command modifier, route directly to the terminal's performKeyEquivalent — bypassing SwiftUI's view hierarchy walk entirely. Also clear stale browserAddressBarFocusedPanelId when a terminal surface has focus, preventing Cmd+N from being eaten by omnibar selection logic after focus transitions away from a browser. Adds DEBUG-only keyboard event ring buffer (KeyDebugLog) that dumps to /tmp/cmux-key-debug.log for diagnosing future key routing issues. * Fix split focus and Cmd+Shift+N swallowed after opening browser Split focus: capture the source terminal's hostedView before bonsplit mutates focusedPaneId, so focusPanel moves focus FROM the old pane instead of from the new pane to itself. Also retry ensureFocus when the new terminal's view has no window yet (matching the existing retry pattern for isVisibleInUI). Cmd+Shift+N: after WKWebView has been in the responder chain, SwiftUI's internal focus system can intercept Command-key events in the content view hierarchy (returning true) without firing the CommandGroup action closure. Fix by dispatching Command-key events directly to NSApp.mainMenu when the terminal is first responder, bypassing the broken SwiftUI path. Also add Cmd+Shift+N to handleCustomShortcut so it's customizable and doesn't depend on SwiftUI menu dispatch at all. * Unified debug event log: merge key/mouse/focus into /tmp/cmux-debug.log - Delete KeyDebugLog, MouseDebugLog, klog(), mlog() from AppDelegate - Replace all klog/mlog calls with dlog() (provided by bonsplit) - Remove debugLogCallback wiring from Workspace - Add focus change logging: focus.panel, focus.firstResponder, split.created, focus.moveFocus - Add import Bonsplit where needed for dlog access - Fix stale drag state on cancelled tab drags (bonsplit submodule) * Fix split focus stolen by re-entrant becomeFirstResponder during reparenting During programmatic splits (Cmd+D / Cmd+Shift+D), SwiftUI reparents the old terminal view, which fires becomeFirstResponder → onFocus → focusPanel for the OLD panel, stealing focus from the newly created pane. Add programmaticFocusTargetPanelId guard to suppress re-entrant focusPanel calls for non-target panels during split creation. Also document the unified debug event log in CLAUDE.md. * Clear stale title/favicon when browser navigation fails When a page fails to load (e.g. connection refused), the tab was still showing the previous page's title and favicon. Now didFailProvisionalNavigation resets pageTitle to the failed URL and clears faviconPNGData. * Fix Cmd+N swallowed by browser omnibar and improve split focus suppression - Only Ctrl+N/P trigger omnibar navigation, not Cmd+N/P (Cmd+N should always create new workspace regardless of address bar focus) - Move split focus suppression from workspace-level guard to source: suppress becomeFirstResponder side-effects (onFocus + ghostty_surface_set_focus) directly on the old GhosttyNSView during reparenting, preventing both model-level and libghostty-level focus divergence - Remove programmaticFocusTargetPanelId from Workspace.focusPanel * Fix omnibar hang, WebView white flash, drag-over-browser, and idle CPU spin - Omnibar: first click selects all without entering NSTextView tracking loop; subsequent clicks have 3s synthetic mouseUp safety net to prevent hang - WebView: set underPageBackgroundColor to match window so new browsers don't flash white before content loads - Drag/drop: register custom UTType (com.splittabbar.tabtransfer) in Info.plist so WKWebView doesn't intercept tab drags; override registerForDraggedTypes on CmuxWebView as belt-and-suspenders - CPU: fix infinite makeFirstResponder loop in controlTextDidEndEditing by checking both the text field and its field editor (the actual first responder)
62 lines
2.8 KiB
Swift
62 lines
2.8 KiB
Swift
import AppKit
|
|
import WebKit
|
|
|
|
/// WKWebView tends to consume some Command-key equivalents (e.g. Cmd+N/Cmd+W),
|
|
/// preventing the app menu/SwiftUI Commands from receiving them. Route menu
|
|
/// key equivalents first so app-level shortcuts continue to work when WebKit is
|
|
/// the first responder.
|
|
final class CmuxWebView: WKWebView {
|
|
override func performKeyEquivalent(with event: NSEvent) -> Bool {
|
|
// Let the app menu handle key equivalents first (New Tab, Close Tab, tab switching, etc).
|
|
if let menu = NSApp.mainMenu, menu.performKeyEquivalent(with: event) {
|
|
return true
|
|
}
|
|
|
|
// Handle app-level shortcuts that are not menu-backed (for example split commands).
|
|
// Without this, WebKit can consume Cmd-based shortcuts before the app monitor sees them.
|
|
if AppDelegate.shared?.handleBrowserSurfaceKeyEquivalent(event) == true {
|
|
return true
|
|
}
|
|
|
|
return super.performKeyEquivalent(with: event)
|
|
}
|
|
|
|
override func keyDown(with event: NSEvent) {
|
|
// Some Cmd-based key paths in WebKit don't consistently invoke performKeyEquivalent.
|
|
// Route them through the same app-level shortcut handler as a fallback.
|
|
if event.modifierFlags.intersection(.deviceIndependentFlagsMask).contains(.command),
|
|
AppDelegate.shared?.handleBrowserSurfaceKeyEquivalent(event) == true {
|
|
return
|
|
}
|
|
|
|
super.keyDown(with: event)
|
|
}
|
|
|
|
// MARK: - Drag-and-drop passthrough
|
|
|
|
// WKWebView inherently calls registerForDraggedTypes with public.text (and others).
|
|
// Bonsplit tab drags use NSString (public.utf8-plain-text) which conforms to public.text,
|
|
// so AppKit's view-hierarchy-based drag routing delivers the session to WKWebView instead
|
|
// of SwiftUI's sibling .onDrop overlays. Rejecting in draggingEntered doesn't help because
|
|
// AppKit only bubbles up through superviews, not siblings.
|
|
//
|
|
// Fix: prevent WKWebView from registering as a drag destination entirely. AppKit won't
|
|
// route drags here, so they reach the SwiftUI overlay drop zones as intended.
|
|
override func registerForDraggedTypes(_ newTypes: [NSPasteboard.PasteboardType]) {
|
|
// No-op: suppress WKWebView's automatic drag type registration.
|
|
}
|
|
|
|
override func willOpenMenu(_ menu: NSMenu, with event: NSEvent) {
|
|
super.willOpenMenu(menu, with: event)
|
|
|
|
for item in menu.items {
|
|
// Rename "Open Link in New Window" to "Open Link in New Tab".
|
|
// The UIDelegate's createWebViewWith already handles the action
|
|
// by opening the link as a new surface in the same pane.
|
|
if item.identifier?.rawValue == "WKMenuItemIdentifierOpenLinkInNewWindow"
|
|
|| item.title.contains("Open Link in New Window") {
|
|
item.title = "Open Link in New Tab"
|
|
}
|
|
}
|
|
}
|
|
}
|