Closed Bug 1438538 Opened 3 years ago Closed 3 years ago

The microphone icon from the URL bar is not displayed if you activate your microphone

Categories

(Core :: WebRTC: Audio/Video, defect, P1)

60 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla60
Tracking Status
firefox-esr52 --- unaffected
firefox58 --- unaffected
firefox59 --- unaffected
firefox60 + verified

People

(Reporter: Ovidiu, Assigned: pehrsons)

Details

(Keywords: regression)

Attachments

(1 file)

Affected versions]:

Tested on Nightly 60.0a1(2018-02-14)

[Affected platforms]:

Tested on Mac 10.12, Windows 10, Ubuntu 16.04

[Steps to reproduce]:

Prerequisites:
 Make sure you have connected 1 microphone.
 
 STR:

1. Open Firefox and go to https://mozilla.github.io/webrtc-landing/gum_test.html
2. Click on "Audio" and Allow
 

[Expected result]:

In the left side of the URL bar, a red microphone icon is displayed. 

[Actual result]:

In the left side of the URL bar, a red microphone icon is not displayed. 


Note: This is a regression. 

Here is the regression range:

39:43.08 INFO: Last good revision: 3018e377678c88dd85fd6dec8bda445a9e894141
39:43.08 INFO: First bad revision: 93a8b769cb7a76aa8eb1c0b182c84d5bdf2fcb71
39:43.08 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3018e377678c88dd85fd6dec8bda445a9e894141&tochange=93a8b769cb7a76aa8eb1c0b182c84d5bdf2fcb71
Andreas can you please take a look at it? Thanks
Flags: needinfo?(apehrson)
[Tracking Requested - why for this release]: Recent regression of privacy critical feature
Assignee: nobody → apehrson
Rank: 9
Flags: needinfo?(apehrson)
Priority: -- → P1
Status: NEW → ASSIGNED
Regressor: https://hg.mozilla.org/mozilla-central/rev/ae1d261df7881bfb980ec4b574badbf63412b8b9

In SourceListener::CapturingAudio:
> -         (!mAudioDevice->mSource->IsFake() ||
> +         (mAudioDeviceState->mDevice->mSource->IsFake() ||

That negation disappeared >_>
Comment on attachment 8952343 [details]
Bug 1438538 - Fix SourceListener::CapturingAudio logic.

https://reviewboard.mozilla.org/r/221604/#review227442

Thanks! I suppose the fact that our tests always use fake prompts makes it impossible to add tests for this...
Attachment #8952343 - Flags: review?(jhofmann) → review+
(In reply to Johann Hofmann [:johannh] from comment #5)
> Comment on attachment 8952343 [details]
> Bug 1438538 - Fix SourceListener::CapturingAudio logic.
> 
> https://reviewboard.mozilla.org/r/221604/#review227442
> 
> Thanks! I suppose the fact that our tests always use fake prompts makes it
> impossible to add tests for this...

Unless we decide to use the UI with fake devices without fake prompts too. Do you know why we don't expose any UI with fake devices?
Flags: needinfo?(jhofmann)
Pushed by pehrsons@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/dd415a969992
Fix SourceListener::CapturingAudio logic. r=johannh
https://hg.mozilla.org/mozilla-central/rev/dd415a969992
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
I verified this on Windows 10 x64 Mac OS X 10.12 and Ubuntu 16.04 with Nightly (2018-02-21) using https://mozilla.github.io/webrtc-landing/gum_test.html test page. I can confirm the fix. When I start an Audio capture the red mic icon is displayed in the left part of the URL bar.
Status: RESOLVED → VERIFIED
(In reply to Andreas Pehrson [:pehrsons] from comment #6)

> > Thanks! I suppose the fact that our tests always use fake prompts makes it
> > impossible to add tests for this...
> 
> Unless we decide to use the UI with fake devices without fake prompts too.
> Do you know why we don't expose any UI with fake devices?

I think the media.navigator.permission.fake pref controls this behavior, so we can change it for specific tests.

We don't expose UI with fake devices by default because a page using fake devices doesn't need user permission for that. Web pages can use fake devices to run automated tests for the web content.

I wouldn't be surprised if there was some historical reasons here too, with some tests using fake devices before we were ready to support testing actual prompts.
I think Florian answered the question, he has more historical context than me anyway. Thanks :)
Flags: needinfo?(jhofmann)
You need to log in before you can comment on or make changes to this bug.