fix(typing): short-circuit verification for targets with no verifiable text

[YuriNachos]

Description

On targets that expose no verifiable accessibility text — GPU-rendered terminals such as Ghostty — waitForFocusedTextVerification polled for the full 5 s timeoutMicros while holding the process-global pasteboard session semaphore. That is the multi-second stall measured in #802 (sub-second → ~8.9 s) whenever dictation was injected into such a target.

The fix short-circuits verification when none of the four verifiable focused-text channels is present (value, selectedRange, appScriptValue, appScriptSelectedRange all nil): sleep a pasteboard-consume window, then release the session as .unavailable. Verifiable targets — any one channel present — keep their existing fast path unchanged.

The consume window is 500 ms (pasteConsumeWindowMicros). action() only enqueues Cmd+V via postToPid; the target then reads NSPasteboard.general asynchronously on its own main thread, and under load (a large paste, a busy main thread during a build) that read can land hundreds of milliseconds later — so restoring the prior pasteboard too eagerly would clobber the transcript before the target consumes it. 500 ms is a conservative floor for a busy terminal to service the paste, yet ~10× under the 5 s timeout, so the #802 stall is gone.

Diff: Sources/Fluid/Services/TypingService.swift plus one test file.

Type of Change

• 🐞 Bug fix
• ✨ New feature
• 💥 Breaking change
• 🧹 Chore
• 📝 Documentation update

Related Issue or Discussion

Closes #802.

Testing

• Tested on Apple Silicon Mac
• Tested on Intel Mac
• Tested on macOS version: 26.0 (Darwin 25.6.0), Xcode latest-stable
• Ran linter locally: swiftlint --strict --config .swiftlint.yml Sources → 0 violations, 0 serious in 139 files
• Ran tests locally: xcodebuild 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_transcribesFixture

Two new cases, both in TypingServiceTransientPasteboardTests (suite passes in full):

• testFocusedTextSnapshotWithoutVerifiableChannelShortCircuitsVerification — pins the predicate: all-four-nil is unverifiable; any single non-nil channel is verifiable.
• testWaitForFocusedTextVerificationShortCircuitsUnverifiableTargetInBoundedTime — behavioural: drives the real waitForFocusedTextVerification with an unverifiable snapshot (real pid, all four channels nil) and asserts it returns .unavailable in under timeoutMicros / 2. Remove the short-circuit and it polls to .timeout at ~5 s, failing both asserts.

Two unrelated tests are red on my machine only, for the environment reasons this repo's own prerequisites document, and both are red on a clean main here too:

• HotkeyShortcutTests.testKeyboardPayloadIgnoresStrayMouseButtonField — asserts the ASCII glyph at a keyCode; my host has a non-U.S. input source active.
• DictationE2ETests.testAppPromptBinding_defaultFallbackIgnoresGlobalSelection — reads real com.FluidApp.app defaults, which are customised on this machine.

Neither touches the typing-verification path. CI runs on a clean U.S.-layout runner, so both should be green there.

Screenshots / Video

• No UI/visual changes; screenshots/video are not applicable.

This is a backend typing-verification timing path — no view, layout, styling, settings, overlay or menu-bar surface is touched. The user-observable effect is latency: dictating into Ghostty returns in well under a second instead of ~8.9 s.

Notes

• Verifiable targets are byte-identical to main; only the all-channels-nil case takes the new branch.
• The consume window is a named constant (pasteConsumeWindowMicros) so it is easy to tune if a slower target turns up.
• A few private declarations (FocusedTextSnapshot, PasteVerificationResult, waitForFocusedTextVerification) became internal so the short-circuit path can be exercised by tests; none of them are public API.

[github-actions]

The PR Policy check is blocking this PR because required template information is missing.

Please update the PR description with:

• Testing
• Screenshots / Video

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-apps]

Greptile Summary

The PR avoids a five-second focused-text verification poll when the target exposes no verifiable accessibility or AppleScript text channel.

• Adds a 500 ms pasteboard-consumption window before restoring clipboard contents for unverifiable targets.
• Adds predicate and behavioral tests covering channel detection and bounded short-circuit timing.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

_{Reviews (3): Last reviewed commit: "fix(typing): give unverifiable targets a..." | Re-trigger Greptile}

[YuriNachos]

Saw the 1.6.9 fixes ship earlier today — nice to see the release come together. This PR has been green for most of a week now (build, SwiftLint, the policy check and Greptile all pass), so I wanted to ask whether anything in the approach gives you pause — for example the 500 ms paste-consume window before the clipboard is restored — or whether it just hasn't had a review pass yet. Happy to make the window tunable, extend the behavioural tests, or rebase onto the release if any of that would help.