target.com - Microphone permission is requested repeatedly for each voice search with Speech Recognition enabled
Categories
(Web Compatibility :: Site Reports, defect, P3)
Tracking
(Webcompat Priority:P3, Webcompat Score:4, firefox157 affected)
| Tracking | Status | |
|---|---|---|
| firefox157 | --- | affected |
People
(Reporter: bfarkas, Assigned: padenot)
References
(Blocks 1 open bug, )
Details
(Keywords: webcompat:platform-bug, webcompat:site-report, Whiteboard: [autowebcompat:processed][autowebcompat:repro-failed][webcompat:sightline][webcompat:core])
User Story
autowebcompat-repro-status:failed autowebcompat-repro-reason:not_web_platform autowebcompat-repro-report-os:all platform:windows,mac,linux impact:annoyance configuration:general affects:some branch:release diagnosis-team:media user-impact-score:90
Attachments
(3 files)
Environment:
Operating system: Windows 10
Firefox version: Firefox Nightly 157.0a1 (2026-09-03)
Preconditions:
- Clean profile
Steps to reproduce:
- Navigate to: https://www.target.com
- Click the 'Voice Search' button, then enable microphone permission
- Perform a search using any term
- Click the 'Voice Search' button again
- Observe the page
Expected Behavior:
The user can search again without being asked to grant microphone permission
Actual Behavior:
Microphone permission is requested again, for each voice search
Notes:
- This issue was identified during speech recognition testing phase
- Reproducible on the latest Nightly
- Reproducible regardless of the ETP setting
- Works as expected using Chrome
|
Reporter | |
Updated•26 days ago
|
|
||
Updated•26 days ago
|
|
|
||
Updated•26 days ago
|
|
||
Updated•26 days ago
|
|
|
Reporter | |
Updated•26 days ago
|
|
Assignee | |
Comment 1•26 days ago
|
||
Hrm jib, what's going on here? Is Chrome opening the microphone/keeping permission without a prompt? Can you make sense of the video?
|
|
Assignee | |
Comment 2•23 days ago
|
||
SpeechRecognition.start() acquires the microphone via getUserMedia() and drops
the track when the session ends, so every later session relies on the WebRTC
device grace period. Cover that across reload and same-origin navigation, and
that a replaced device prompts again.
The fake audio device now takes its name (and hence its device id) from
media.getusermedia.fake-microphone-name, mirroring the camera, so a test can
imitate the microphone being swapped out.
|
||
Updated•23 days ago
|
|
||
Updated•23 days ago
|
|
|
||
Updated•22 days ago
|
|
||
Comment 3•22 days ago
|
||
I can repro comment 0 on macOS, so this likely affects all desktop platforms, which for now (bug 1796461) is where we implement permission grace periods (bug 1697284).
As I recall, our "Allowed Temporarily" microphone permission on desktop has a grace period that extends for 60 minutes OR until tab close OR until cross-origin navigation, whichever is sooner. By extension, this applies to speech as well, but is not specific to speech.
This means you can navigate same-site without reprompt for speech/mic. But if you navigate to a different origin and then hit the "Back" button, you're reprompted for speech/mic. — I've confirmed this using https://jan-ivar.github.io/dummy/speech.html
I'm not sure what https://target.com is doing different. After I hit the voice search icon and speak "brown shirt" in Nightly, it searches for "brown" (a different bug?) it appears to navigate to https://www.target.com/s?searchTerm=brown which _looks _same origin to me... But even if I hit the "Back" button I'm still reprompted.
Any chance target is briefly doing a redirect to a different origin or something else clever? I can't tell.
|
||
Comment 4•22 days ago
|
||
I had trouble getting target to transcribe anything on my mac. Here's a webrtc profile with logging on two attempts.
|
||
Comment 5•12 days ago
|
||
Sorry, what's the question for me?
As I recall, our "Allowed Temporarily" microphone permission on desktop has a grace period that extends for 60 minutes OR until tab close OR until cross-origin navigation, whichever is sooner. By extension, this applies to speech as well, but is not specific to speech.
Yes that sounds accurate.
|
|
Assignee | |
Comment 6•12 days ago
|
||
https://share.firefox.dev/4h2tkUk is an about:logging WebRTC of this on target.com. Scenario was: load target.com, click mic icon, accept doorhanger, refresh, re-click the mic icon, door-hanger shows again (unexpected, the grace period should have worked).
|
|
Assignee | |
Comment 7•12 days ago
|
||
Child browsing contexts share their top-level browser's BrowserId. Clearing all
browser-scoped permissions when any subframe was discarded removed unrelated
grants for the entire tab, including WebRTC device grace permissions created
during reload.
Browser-scoped permissions are also keyed by principal and permission type. A
subframe that used getUserMedia therefore retains only its origin- and
device-specific grace grant when it is removed or navigated, and another origin
cannot consume it. The timer still expires the grant, and discarding the
top-level context clears all grants for the tab.
Treat only top-level discard as tab teardown. Tests cover active
SpeechRecognition across reload and a subframe-principal grant across frame
recreation.
Description
•