mirror of
https://github.com/ghostty-org/ghostty.git
synced 2025-08-02 14:57:31 +03:00
macOS: Fix new window focus when created from quick terminal (#5834)
## Root Cause
The issue has two aspects:
1. The window creation process didn't explicitly force focus on the new
window after showing it.
2. More fundamentally, we were relying on `NSApp.isActive` to determine
whether to activate the application, which is problematic because:
- When creating a window from quick terminal, the application is already
"active" but this active state is owned by the quick terminal
- The [`NSApp.isActive`
check](4cfe5522db/macos/Sources/Features/Terminal/TerminalManager.swift (L100)
)
doesn't accurately reflect our intent - creating a new window is an
explicit user action that should always result in that window gaining
focus
## Solution
Removing the `NSApp.isActive` check.
```swift
// Before
if !NSApp.isActive {
NSApp.activate(ignoringOtherApps: true)
}
// After
NSApp.activate(ignoringOtherApps: true)
```
Fixes #5688
This commit is contained in:
@ -95,11 +95,8 @@ class TerminalManager {
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
// If our app isn't active, we make it active. All new_window actions
|
// All new_window actions force our app to be active.
|
||||||
// force our app to be active.
|
|
||||||
if !NSApp.isActive {
|
|
||||||
NSApp.activate(ignoringOtherApps: true)
|
NSApp.activate(ignoringOtherApps: true)
|
||||||
}
|
|
||||||
|
|
||||||
// We're dispatching this async because otherwise the lastCascadePoint doesn't
|
// We're dispatching this async because otherwise the lastCascadePoint doesn't
|
||||||
// take effect. Our best theory is there is some next-event-loop-tick logic
|
// take effect. Our best theory is there is some next-event-loop-tick logic
|
||||||
|
Reference in New Issue
Block a user