fix(typing): stop raising every window of the target app when restoring focus after dictation - #810
Conversation
|
The PR Policy check is blocking this PR because required template information is missing. Please update the PR description with:
Screenshots or video are required for UI, UX, settings, onboarding, overlay, menu bar, or visual behavior changes. If this PR has no visual changes, check the no-visual-change box in the template. If this remains incomplete for 48 hours after opening, the PR may be closed. |
Greptile SummaryThis PR narrows post-dictation activation to avoid raising every window belonging to the target application.
|
ffd6547 to
752c3df
Compare
|
Force-pushed a housekeeping fix: the branch accidentally carried an internal report file from my own tooling directory that has nothing to do with this change. It is gone now — the diff is only the source and test files listed above. No production or test code changed in this push; the branch is otherwise identical to what was reviewed. |
|
@YuriNachos Love all your PRs!!! The gold standard contributions I was hoping to get!!!! |
…ng focus after dictation Drop .activateAllWindows from the focus-restore activation options in TypingService.activateApp(pid:); keep .activateIgnoringOtherApps so the target app is still brought forward without raising every window of a multi-window app (WebStorm, multi-window Xcode, browsers) on each dictation. Issue altic-dev#748. The inline options literal is extracted into a named internal testable seam (focusRestoreActivationOptions) and a regression test is added to the existing TypingServiceTransientPasteboardTests asserting the option set contains .activateIgnoringOtherApps and not .activateAllWindows. Co-Authored-By: Claude <noreply@anthropic.com>
752c3df to
81ac1c3
Compare
Description
After dictation, FluidVoice restores focus to the target app through
TypingService.activateApp(pid:), which calledNSRunningApplication.activate(options: [.activateAllWindows, .activateIgnoringOtherApps])..activateAllWindowsraises every window of the target process, not just the one the user was typing into. On a multi-window app (WebStorm, VS Code, multiple Finder windows) that reshuffles the whole window layout after each dictation — the behaviour reported in #748.This PR removes
.activateAllWindowsand keeps.activateIgnoringOtherApps, so the target app still becomes frontmost and its key window comes forward, while sibling windows stay where the user left them.The options are now built from one named constant,
TypingService.focusRestoreActivationOptions, so the four focus-restore call sites (all of which already funnel throughactivateApp(pid:)) share a single definition and the contract is unit-testable.Diff:
Sources/Fluid/Services/TypingService.swift(+8/-1) and one test.Type of Change
Related Issue or Discussion
Closes #748.
Testing
swiftlint --strict --config .swiftlint.yml Sources→ 0 violations, 0 serious in 139 filesxcodebuild test -project Fluid.xcodeproj -scheme Fluid -destination 'platform=macOS,arch=arm64' CODE_SIGNING_REQUIRED=NO CODE_SIGNING_ALLOWED=NO -skip-testing:FluidDictationIntegrationTests/DictationE2ETests/testDictationEndToEnd_whisperTiny_transcribesFixtureNew regression test —
TypingServiceTransientPasteboardTests.testFocusRestoreDoesNotRaiseAllWindowsOfTargetApp: assertsfocusRestoreActivationOptionscontains.activateIgnoringOtherAppsand does not contain.activateAllWindows. It is red onmain(the option set still carries.activateAllWindows) and green here.TypingServiceTransientPasteboardTestspasses in full.Two unrelated tests are red on my machine only, both for the environment reasons documented in this repo's own prerequisites, and both are red on a clean
mainhere too:HotkeyShortcutTests.testKeyboardPayloadIgnoresStrayMouseButtonField— asserts the ASCII glyph at a keyCode; my host has a non-U.S. input source active.DictationE2ETests.testAppPromptBinding_defaultFallbackIgnoresGlobalSelection— reads realcom.FluidApp.appdefaults, which are customised on this machine.Neither touches
TypingService. CI runs on a clean U.S.-layout runner, so both should be green there.Manual check for the actual behaviour (it cannot be captured in a screenshot): open two windows of a multi-window app, focus one, dictate into it. On
mainboth windows are raised; with this change only the focused window comes forward.Screenshots / Video
To be explicit rather than just tick a box: this PR changes no FluidVoice UI surface — no view, layout, styling, settings, overlay or menu-bar change. What it changes is which windows of the target third-party app macOS raises when focus is restored; that is window-activation behaviour in another process, which a static screenshot cannot show. The manual repro steps above are the way to observe it.
Notes
.activateIgnoringOtherAppsalone already brings the app frontmost with its key window.focusRestoreActivationOptionsisinternal staticso the test target can reach it via@testable import; no new public surface.Authored by
@YuriNachos. Implementation written by acccc(Claude Code) worker under orchestrator acceptance; an independent adversarial review (logic + behaviour-equivalence + test-integrity) returned APPROVE with no blocking findings.