feat(lock): add secure-input policy for password fields#53
Conversation
Issue #52: in Chrome password fields the OS coerces the keyboard to ABC via secure event input, and LockIME sometimes never reverted to the locked source. The state machine is purely event-driven, so a mismatch that goes *stable* with no follow-up notification — the secure-field ASCII coercion, or a flaky background CJKV `select` — was never re-examined and stayed stuck on ABC. Add a `revertsInSecureInput` toggle (General ▸ Password Fields, off by default). Off, LockIME respects macOS secure input and leaves the coercion alone; on, it keeps enforcing the locked source even there. The policy threads config → `LockEngine.apply` → `LockController` and gates enforcement on the process-global `IsSecureEventInputEnabled()`, covering the continuous lock and autonomous one-shot switches alike; the explicit `lockime://switch-source` API stays ungated. Two enabling fixes make it work. Every `force` now arms a bounded trailing reconcile (`maxReconcileRetries`) that re-checks once the settle window closes, so a switch that silently didn't take is corrected without waiting on a notification that never comes. And because leaving a password field ends secure input without reliably posting a source-change notification, respect mode polls `IsSecureEventInputEnabled()` (`secureInputPollInterval`) only while a secure field keeps it gated, re-asserting the lock the instant secure input turns off. The scheduler and secure-input probe are injected so the state machine stays deterministically testable. Refs #52 Signed-off-by: Kevin Cui <bh@bugs.cc>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 16 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (11)
✨ Finishing Touches✨ Simplify code
Comment |
1 participant
In Chrome password fields the OS coerces the keyboard to ABC via macOS secure event input, and LockIME sometimes never reverted to the locked source — you'd land on ABC and stay there. The lock's state machine is purely event-driven, so a mismatch that goes stable with no follow-up notification (the secure-field ASCII coercion, or a flaky background CJKV
select) was never re-examined; and leaving the field ends secure input without reliably posting a source-change notification, so nothing re-triggered the lock on blur.This adds an Enforce in password fields toggle (General ▸ Password Fields,
revertsInSecureInput, off by default). Off, LockIME respects macOS secure input and leaves the coercion alone; on, it keeps enforcing the locked source even there. The policy threads config →LockEngine.apply→LockControllerand gates enforcement on the process-globalIsSecureEventInputEnabled(), covering the continuous lock and autonomous one-shot switches alike; the explicitlockime://switch-sourceAPI stays ungated.Two enabling fixes make it work:
forcearms a bounded re-check (maxReconcileRetries) that runs once the settle window closes, so a switch that silently didn't take is corrected without waiting on a notification that never comes.IsSecureEventInputEnabled()(secureInputPollInterval) only while a secure field keeps it gated, re-asserting the lock the instant secure input turns off.The scheduler and secure-input probe are injected so the state machine stays deterministically testable; new tests cover the reconcile and retry cap, the gate in both modes, the one-shot exemption, poll-driven recovery with no blur notification, and the config round-trip. Every user-facing string is translated for all nine
SupportedLanguagecases.Verification. All 345 tests pass. On a real machine I confirmed the respect behavior and the poll's detect→re-force logic end to end via
os_log: leaving a synthetic secure field that posts no notification, the poll fires and re-forces the target. I could not drive Chromium's native secure input under CDP automation, so the last mile — the frontmost app visibly switching back to your IME in real Chrome — is unverified here and worth a manual smoke test (lock to your IME, type in a Chrome password box, tab to a normal field, confirm it returns within ~0.5s). If a frontmost app freshly out of secure input resists the background switch, the follow-up is to forceFocusNudgeon the secure-input recovery path.Closes #52