W-572: trigger reliably in Slack and other Electron apps

[wr]

Problem

Mojito's : trigger fired in Slack only ~10% of the time, while working everywhere else. The reported theory was event-tap startup sequencing.

Actual cause

The event tap was fine. Every dropped Slack trigger was hitting the secure-field guard. Instrumentation confirmed the mechanism: haveInfo=false role=nil elem=false on every attempt — the focused-element cache was nil for Slack.

Chromium/Electron apps don't build their accessibility tree until a client sets AXManualAccessibility on the app element. Until then AXUIElementCopyAttributeValue(app, focusedUIElement) returns nothing, the seed caches nil, and AppContextDetector.current() fails closed (unknown focus → secure) and drops the trigger. Native apps (Mail, Messages) expose focus by default, so only Electron apps broke. The rare successes lined up with a relaunch catching the tree already built.

Fix

Set AXManualAccessibility on the app element at seed time (FocusedElementCache.seed). Native apps don't implement it and ignore the set; Chromium flips into full AX mode and exposes its focused AXTextArea, which classifies as editable / non-secure and drives the picker normally.

The fix does not weaken the secure-field guard — a real password field still classifies as AXSecureTextField and stays blocked.

Diagnostics (also in this PR)

• haveInfo / role / elem / editable on the secureFieldBlocked log line.
• Field-classification state (focusedHaveFieldInfo, focusedIsSecure, focusedClassifiedRole, focusedElementNil) in the debug report's Now section.

These flow to both the in-app report and the MOJITO_E2E_LOG stream.

Test plan

Verified end-to-end on a live Debug build in Slack (macOS 27):

engine.colon excluded=false          → capture opened
picker.open  outcome=elementTopLeft  → picker showed
insert.exactMatch                    → emoji inserted

Last-picker-context confirmed Slack's compose box now exposes the full Chromium AX tree (AXTextArea, ChromeAXNodeId, AXDOMClassList). Unit suite (scripts/run-tests.sh) passes.

Note

Enabling Chromium accessibility adds a small ongoing AX-tree cost inside each Electron app (the same tradeoff VoiceOver makes). Necessary for Mojito to function there at all.

Refs W-572

[linear-code]

W-572

[wr-claude-reviewer]

The root-cause diagnosis and fix are solid. AXManualAccessibility is the right lever, placed at the right time (before the observer fires in seed), and the existing seedTimeout on axApp bounds how long that set can block. Native apps silently ignore the attribute, Chromium builds its tree, and the reseed fallback handles the lazy-build race. The secure-field guard is unchanged — AXSecureTextField still classifies and blocks regardless. Diagnostic fields are well-scoped (diagnostics-only, clearly labeled) and the tuple-type extension through classify → publishFieldInfo → ActiveContext is clean.

Nit: DebugReport.swift now emits both focusedElementCached: \(element != nil) (pre-existing) and focusedElementNil: \(cache.element == nil) (new) — they're boolean inverses of each other. Not harmful, but one of them is redundant.

[wr]

Follow-up hardening (from review of the first commit)

Review flagged that the initial fix widened exposure without tightening the secure-field guard. Two follow-ups, pushed:

1. Secure-field detection now catches web/Electron password fields.
isSecure matched role == "AXSecureTextField", but that string is a subrole, not a role — there is no secure role constant. Native NSSecureTextField and Chromium/WebKit <input type=password> all report role AXTextField with subrole AXSecureTextField, so the old role-only check never matched a real password field. It now matches the subrole (role kept as a zero-cost defensive OR). Confirmed against Chromium (browser_accessibility_cocoa.mm), WebKit (WebAccessibilityObjectWrapperMac.mm), and Apple's AXRoleConstants.h. This is what protects Electron/web password fields now that their AX trees are enabled — they no longer lean on the exclusion list.

2. AXManualAccessibility is now scoped to apps that need it.
Previously set on every app on every activation. Now set only when the focused-element read comes back empty — native apps always return an element and are never touched; only tree-gating apps (Electron/Chromium) get the flag, and only when focused. Also moved past the seed generation guard.

Verification

• Slack: still triggers (regression check passed).
• Helium (Chromium browser): triggers — confirms the fix generalizes beyond Slack.
• Native apps (Messages): unaffected.
• Gap: I did not get a clean live keystroke test in an actual password field. The subrole block rests on authoritative source confirmation + the code, not a live repro. Worth one manual check before/after merge.

[wr-claude-reviewer]

The fix is correct and well-scoped. A few notes:

What looks good

• AXManualAccessibility is gated on seeded == nil — native apps that already return a focused element are never touched. Electron apps that return nil get the flag set once; Chromium remembers it for the lifetime of the process, so subsequent visits won't re-set it unnecessarily but are also harmless if they do.
• The subrole check for AXSecureTextField is the right fix now that Electron AX trees are exposed. Native NSSecureTextField reports role AXTextField with subrole AXSecureTextField, so the old role-only check silently missed it. The role OR is kept as a zero-cost defensive fallback and the comment explains the distinction clearly.
• Both secureFieldBlocked call sites get the same diagnostic fields, so the log is consistent regardless of which path trips it.
• focusedRole is correctly nil-ed in element's didSet so a stale role from the previous focus can't bleed into the next one.

Nit

DebugReport.now() now emits both focusedElementCached (existing) and focusedElementNil (new). These are the exact inverse of each other and read from the same cache instance, so one is redundant. Could drop focusedElementNil and rely on focusedElementCached, or rename the existing line to focusedHaveElement for symmetry with the new focusedHaveFieldInfo — either way it's a minor polish item, not a blocker.

[wr]

Gap closed: live-tested a password field in a Chromium browser — the picker stays hidden, is not captured. Secure-field block confirmed. Full matrix now verified: Slack ✓, Helium/Chromium ✓, native (Messages) ✓, password field blocked ✓.