Re-examine mobile fail-closed restriction on Browser on-device (native SpeechRecognition) STT

[heavygee]

Context

web/src/hooks/browserLocalSpeech.ts gates the "Browser on-device" dictation provider (native window.SpeechRecognition) behind isConfirmedDesktopSpeechEnvironment(), which blanket-rejects mobile and unknown-UA browsers. The code comment explains why: some Android WebViews expose a partial SpeechRecognition shape whose available() call crashes the renderer, so the safe default became "desktop only."

Documented at docs/guide/voice-assistant.md:31.

Ask

Investigate whether this restriction is still necessary as a blanket policy, or whether it can be scoped more precisely (e.g. detect the specific broken WebView shape rather than reject all mobile/unknown UAs). Operator wants full parity across web — mobile should not be a second-class citizen for STT if it can be done safely.

Scope

• Reproduce or confirm the original crash report/motivation for the blanket restriction (git blame / PR history on browserLocalSpeech.ts).
• Test actual behavior on real mobile browsers (Chrome Android, Safari iOS, common Android WebView versions) — does SpeechRecognition.available() still crash, or was this fixed upstream in newer WebView versions?
• Propose either: (a) a safe way to detect and allow working mobile environments, or (b) confirm the blanket restriction is still the right call and document why more precisely.
• Do NOT implement the search-box long-press-to-talk feature — that is a separate peer/issue.

Not in scope

• Adding a new STT backend (native browser STT already exists and is shipped).
• The search-box UI work (tracked separately).

[github-actions]

Confirmed: the fail-closed policy was introduced for a real regression, but the repository does not contain enough evidence to safely narrow it yet.

Issue #1348 records that HAPI 0.25.4 called SpeechRecognition.available() while mounting the session composer and when changing voice language. In affected Android System WebView/OEM browsers, that native call terminated or reloaded the renderer instead of rejecting a JavaScript promise. PR #1349 moved the call to explicit dictation startup and added the current desktop-only gate; the original reporter verified that patched build on the affected browser.

The current policy is broader than detection of one broken API shape:

• Eligibility requires UA Client Hints with mobile === false and an allowlisted desktop platform. The ordinary user-agent string is unused, so every mobile or missing/unknown-UA-CH environment is rejected before API inspection.
• The non-invasive shape check only verifies a callable constructor, processLocally on its prototype, and a static available data property without invoking getters.
• available() is invoked only after explicit start, with abort/concurrency/timeout handling. Those JavaScript controls cannot recover if the native bridge terminates the renderer.

I did not find an exact affected WebView/OEM version, a captured descriptor/API shape from that runtime, an upstream Chromium/WebView bug, or a real-device compatibility matrix in the repository/history. Therefore a specific broken-shape or version exclusion is not currently derivable from verified evidence. A safe relaxation should use a positive, pre-call signal for known-good mobile environments and validate it on real devices; probing available() and catching an error is not sufficient for the known failure mode.

Relevant code:

• web/src/hooks/browserLocalSpeech.ts:59 - desktop platform allowlist and UA-CH-only eligibility gate.
• web/src/hooks/browserLocalSpeech.ts:76 - descriptor-based shape inspection without invoking the native method/getters.
• web/src/hooks/browserLocalSpeech.ts:90 - environment gate runs before API-shape checks.
• web/src/hooks/realtimeTranscription.ts:340 - bounded explicit availability probe.
• web/src/hooks/realtimeTranscription.ts:456 - native probe occurs only when browser-local dictation starts; recognition remains processLocally = true.
• web/src/hooks/browserLocalSpeech.test.ts:50 - tests cover mobile and missing-UA-CH rejection, but only with mocks.
• docs/guide/voice-assistant.md:31 - current documented policy.

Need more info:

• Exact device, Android version, browser/OEM package, and Android System WebView version from the original regression(web): opening a session crashes Android System WebView browsers in v0.25.4 #1348 reproduction, if available.
• Real-device results for current Chrome Android, affected WebView-based browsers, and Safari iOS, including the exposed constructor/prototype/static property descriptors before any native call.

---

HAPI Bot