Drop host-AX-publish ceiling to 60ms now that swallow bug is fixed#383
Merged
Conversation
FuJacob
added a commit
that referenced
this pull request
May 28, 2026
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
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.
Now that #382 makes the accept tap fail-open, the long publish wait no longer masks an input-swallow bug. Dropping the ceiling from 400ms to 60ms keeps post-divergence predictions snappy.
Greptile Summary
Reduces the AX-publish wait ceiling in
pollForHostPublishfrom 400ms to 60ms, relying on the fail-open accept tap added in #382 to ensure keystrokes are never swallowed regardless of AX timing. WithhostPublishPollIntervalMs = 30, the new ceiling allows exactly one async retry (at ~30ms wall time) before the loop falls back to generating against whatever AX state is current.hostPublishWaitCeilingMsdrops 400 → 60ms; Chrome contenteditable fields on busy pages that publish AX after 30ms will now receive predictions against pre-keystroke text more often, which is explicitly accepted as a quality tradeoff for snappier predictions.Confidence Score: 4/5
Safe to merge; the one-line constant change is well-reasoned and the poll-loop fallback ensures predictions always fire even if AX never updates.
The change is minimal and intentional. The only gap is a now-stale comment on
hostPublishPollIntervalMsthat still cites "default 80ms" — a value that would exceed the new 60ms ceiling and eliminate all async retries if someone tried to match it. That is a documentation hazard, not a current defect.The poll-interval comment at lines 184–187 in
SuggestionCoordinator+Input.swiftis the only part worth revisiting.Important Files Changed
hostPublishWaitCeilingMsfrom 400ms to 60ms; with the 30ms poll interval this yields exactly one async AX retry before giving up — the poll-interval comment still references "default 80ms" which now exceeds the ceiling and would eliminate all retries if used.Flowchart
%%{init: {'theme': 'neutral'}}%% flowchart TD A[Keystroke received via CGEvent tap] --> B[schedulePredictionAfterHostPublishDelay] B --> C[Snapshot baseline: text, elementID, selectionLocation] C --> D[pollForHostPublish\nelapsedMs = 0] D --> E[focusModel.refreshNow\nsynchronous AX read] E --> F{AX snapshot\nchanged?} F -- Yes --> G[schedulePrediction] F -- No --> H["nextElapsed = elapsedMs + 30ms\n(hostPublishPollIntervalMs)"] H --> I{"nextElapsed < 60ms?\n(hostPublishWaitCeilingMs)"} I -- "Yes (0+30=30 < 60)" --> J[asyncAfter 30ms] J --> K[pollForHostPublish\nelapsedMs = 30] K --> L[focusModel.refreshNow] L --> M{AX snapshot\nchanged?} M -- Yes --> G M -- "No: 30+30=60 >= 60\n(ceiling hit)" --> G I -- "No (fires immediately if\npollInterval >= ceiling)" --> G style G fill:#4CAF50,color:#fff style I fill:#FF9800,color:#fffComments Outside Diff (1)
Cotabby/App/Coordinators/SuggestionCoordinator+Input.swift, line 184-187 (link)hostPublishPollIntervalMscomment says it is the "same order of magnitude as the focus poll itself (default 80ms)" — but with the ceiling now at 60ms, any poll interval at or above 60ms would cause the ceiling guard (nextElapsed < hostPublishWaitCeilingMs) to fire immediately on the first tail-call, giving zero async retries. Even using the 80ms value mentioned in the comment would silently eliminate all polling. The comment should be updated to reflect the new ceiling so future maintainers know the two constants are tightly coupled.Reviews (1): Last reviewed commit: "Drop host-AX-publish ceiling to 60ms now..." | Re-trigger Greptile