[devswha]

Closes #2343. Thanks to @osamahbeig for the report and the diagnosis.

What was wrong

• Safari tab, mic allowed, "permission denied" (browser speech engine, no OpenAI key). MicButton started a take on pointerdown. iOS WebKit lets SpeechRecognition.start() run only from a user activation, and a touch's pointerdown is not one. On the iOS 27 Simulator, a tap logs navigator.userActivation.isActive as false on pointerdown/touchstart and true on pointerup/touchend/click. A 900 ms hold is false throughout and fires no click. So every touch take ended in not-allowed, which we showed as "Microphone permission was denied". The click fallback never ran for a touch, because it skips clicks within 500 ms of a pointerup.
• Home-screen app closes or reloads on Settings > Voice input > On. Choosing On called getUserMedia right away. Nothing else in that path differs from a Safari tab.

Change

• MicButton: with the browser engine and a non-mouse pointer (touch or pen), the tap's click starts or finishes the take. Which of the two is decided at pointerdown, so a take that ends on its own before the click is not started again. A mouse keeps press-and-hold and tap-to-toggle. The server engine (MediaRecorder) keeps press-and-hold on touch too: its getUserMedia and AudioContext resume work from pointerdown, and the Simulator shows the AudioContext reaching running. Only the pointer that pressed may release a hold, so a right-click's pointerup no longer finishes a take. The browser engine's mic is labelled "Dictate" instead of "Dictate (hold)".
• Settings: in an iPhone home-screen app (navigator.standalone), On no longer asks for the microphone at once; the first tap of the mic asks.
• service-not-allowed (the device's recognizer is off, i.e. Siri & Dictation, or has no model for the language) now says "Speech recognition is off or unavailable on this device" instead of blaming the permission. Translated into ko/ja/zh.
• iOS app: NSSpeechRecognitionUsageDescription in Info.plist. WKWebView's speech recognition asks SFSpeechRecognizer for access from the app process, and an app without that key is terminated when it asks. Mirrored in app/store/ios.md.
• DESIGN.md's Voice input section records the tap/hold rules.

Design reference: the Claude and ChatGPT iOS apps, and Safari's own dictation fields, start dictation with a tap and stop it with a second tap; a hold is not their gesture. A mouse keeps push-to-talk here because desktop browsers allow it.

Verification

• Fail-first: src/components/VoiceInput.test.tsx failed on main's MicButton (press on touch pointerdown). Its stop-tap and right-click cases failed on the first fix commit. All pass now. src/lib/voice.test.ts pins service-not-allowed -> speech_unavailable.
• bun run check fast is green on b5776e6 (rebased on ddc74b0): 8666 unit tests pass, 0 fail; typecheck, build and generated types are clean.
• iOS 27 Simulator (eamac, own device, WebDriverAgent taps), the demo build with an event hook:
  • main, Safari tab: Settings On calls getUserMedia. On the probe page, a touch pointerdown start runs with isActive=false.
  • fix, Safari tab: a mic tap logs pointerdown (isActive=false) -> pointerup -> click -> SpeechRecognition.start isActive=true. The pill shows "Ready…" and the keyboard stays closed.
  • fix, home-screen app: Auto -> On calls no getUserMedia, and the app does not reload. A mic tap then starts recognition from the click (isActive=true).

Known limits

• The Simulator's WebKit site-permission sheet ignores synthesized taps, so a whole recording through to text was not observed. The home-screen reload itself did not reproduce in the Simulator either: a bare getUserMedia kept its sheet up for 6 minutes with no reload. The Settings change removes the only request that path made. Whether the first mic tap in a home-screen app now triggers the same reload on a real iPhone is unconfirmed, and needs a check on the device (the reporter offered to test a build).
• With the browser engine, holding the mic on a touch screen now does nothing (Android Chrome included), where Chrome used to treat it as push-to-talk. A tap works everywhere.
• In a home-screen app the Settings page can no longer show "Microphone permission was denied". A denial shows in the input's note on the first tap instead.

Reviews

• omo-native-code-reviewer: APPROVE. Its MEDIUM (the changelog claimed the reload was fixed) is resolved: the fragment now says the request was removed, not that the reload is confirmed fixed. Its LOW about the label is fixed; the other LOWs are listed above.
• Codex Sol 6.1 Fast xhigh, round 1: REQUEST_CHANGES with two MEDIUMs, a stop tap restarting a take and a right-click releasing a touch-started take, plus the label. All three are fixed, each with a test that failed before.
• Codex final round, on the delta only: it confirmed those fixes and found two new MEDIUMs.
  • A touch hold on the stop button (which fires no click) left a stale "finish" that swallowed the next Enter or Space. Fixed: a tap's gesture now counts only for a click within 500 ms of its pointerup. A test covers it and failed before.
  • With the server engine, two overlapping touches whose first click arrives while the second is still down can start a second take. It is left as a known limit under the lane's final-round rule. It needs a multi-touch on the mic, which Codex itself could not deliver natively (browsers may suppress that click), and the server engine's pointerdown path is the one main already had.

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 11 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 4 included reviews currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: devswha/ovis
• Branch: fix/ios-pwa-voice-crash
• File: .coderabbit.yaml
• Commit: b5776e6
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: bc102f33-59c0-45f8-851e-ec80354a2dac

Commits

Reviewing files that changed from the base of the PR and between ddc74b0 and b5776e6.

Files selected for processing: 12

• DESIGN.md
• app/ios/App/App/Info.plist
• app/store/ios.md
• changelog.d/ios-voice-input-tap.md
• src/components/SettingsDialog.tsx
• src/components/VoiceInput.test.tsx
• src/components/VoiceInput.tsx
• src/lib/i18n/composer.ja.ts
• src/lib/i18n/composer.ko.ts
• src/lib/i18n/composer.zh.ts
• src/lib/voice.test.ts
• src/lib/voice.ts

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[devswha]

CodeRabbit hit its review limit on this PR, so no CodeRabbit review ran. Two reviews ran in its place, both adversarial and read-only. Their findings and how each was resolved:

omo-native-code-reviewer (on 87da4206): APPROVE

• MEDIUM: no one has confirmed what made the home-screen app reload; the Simulator does not reproduce it. Skipping the request on Settings > On may only move it to the first mic tap, so the changelog should not claim the reload is fixed. Resolved: the fragment and the PR body now say the request was removed, not that the reload is confirmed fixed. A check on a real iPhone is still needed; the reporter offered to test a build.
• LOW: the mic is still labelled "Dictate (hold)". Fixed in 9d41878: the browser engine's mic is labelled "Dictate", translated into ko/ja/zh.
• LOW: holding the mic with the browser engine now does nothing on a touch screen (Android Chrome included). Intended, since browser speech can only start from a click; recorded in DESIGN.md and the PR's known limits.
• LOW: in a home-screen app, the Settings page can no longer show a denied permission. Accepted: a denial still shows in the input's note on the first tap.
• LOW: thin coverage in the new test. Addressed by the three cases added in the later rounds.

Codex Sol 6.1 Fast xhigh, round 1 (on 87da4206): REQUEST_CHANGES

• MEDIUM: if recognition ended between a stop tap's pointerdown and its click, the click started a new take. Fixed in 9d41878: a tap decides at pointerdown whether it starts or finishes the take. Test: "finishes from a stop tap even when the take ended before its click" (failed on 87da4206).
• MEDIUM: a take started by touch kept a stale hold time, so a later right-click's pointerup finished it. Fixed in 9d41878: only the pointer that pressed can release a hold. Test: "lets only the pointer that pressed release a hold" (failed on 87da4206).
• LOW: the "Dictate (hold)" label. Fixed, as above.

Codex final round, on the delta only (on 84153973): REQUEST_CHANGES

• It confirmed the three round-1 fixes.
• MEDIUM: a touch hold on the stop button fires no click, so its pending "finish" made the next Enter or Space finish an idle take instead of starting one. Fixed in b5776e6: a tap's gesture counts only for a click within 500 ms of its pointerup. Test: "drops a touch hold's gesture that got no click" (failed on 84153973).
• MEDIUM, left as a known limit: with the server engine (OpenAI key) still starting a take, two overlapping touches whose first click arrives while the second finger is down can start a second take. This needs a multi-touch on the mic. Codex could not get a real browser to send that click sequence (browsers may suppress clicks during multi-touch), and the server engine's pointerdown path is the one main already had. Per the lane's final-round rule it is not fixed here; it is listed in the PR body.

bun run check fast is green on the final head b5776e6: 8666 unit tests pass, 0 fail.

[devswha]

Merging b5776e6 (closes #2343, thanks @osamahbeig for the report). iOS starts speech recognition only from a user activation, and a touch's pointerdown is none, so with the browser engine a touch now starts or finishes a take from the tap's click (a mouse, and the server engine, keep hold-to-talk); only the pointer that pressed may release a hold. In an iPhone home-screen app, Settings > Voice input On no longer calls getUserMedia (the request that closed or reloaded it); the first mic tap asks instead. service-not-allowed gets its own note, and the iOS app gains NSSpeechRecognitionUsageDescription (takes effect with the next iOS build). Reviewed by the merge pass: the change is confined to MicButton's pointer handlers, the Settings request and one new error key (translated in ja/ko/zh); 4 fail-first tests. Known limits (from the PR body): a whole recording through to text and the home-screen reload were not observed in the Simulator and need a real-iPhone check; with the browser engine a touch hold no longer does push-to-talk (Android Chrome included), a tap works everywhere; the home-screen Settings page no longer shows the denied note (the first tap does). Unreproduced, below HIGH: with the server engine, two overlapping touches whose first click lands while the second is still down can start a second take; that path is unchanged from main.