1224766 - Cannot get microphone share permission when camera share permission is pending and vice versa

Status: VERIFIED FIXED

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

Description

[rdaware]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

Steps to reproduce:

1. Go to a webpage which uses WebRTC and make a call
2. Click send audio and accept share permission
3. Click send video and expect camera share permission dialog box
4. Close camera dialog without accepting or rejecting share permission
5. Stop audio
6. Start audio again and expect microphone share permission dialog box





Actual results:

After step 6, Microphone share dialog box never pop up


Expected results:


microphone dialog box should pop up as Firefox v41

Comment 1

[Florian Quèze [:florian]]

This seems related to bug 861716.

Comment 2

[rdaware]

(In reply to Florian Quèze [:florian] [:flo] from comment #1)
> This seems related to bug 861716.

Hi Florian,

Any update on this issue. This is blocking issue for a Cisco product. Please provide me update if any.

Thanks,
Rahul

Comment 3

[Florian Quèze [:florian]]

I can't reproduce this bug.

The page I used to attempt to reproduce is:
data:text/html,<iframe src="https://people.mozilla.org/~fqueze2/webrtc/"></iframe><iframe src="https://people.mozilla.org/~fqueze2/webrtc/">

After step 6, I do get a microphone permission prompt, and can accept it.

I tried with both a Firefox 42.0 release, and a recent local build (built from up-to-date source yesterday).

Is there a step or a detail I could be missing?

Comment 4

[rdaware]

(In reply to Florian Quèze [:florian] [:flo] from comment #3)
> I can't reproduce this bug.
> 
> The page I used to attempt to reproduce is:
> data:text/html,<iframe
> src="https://people.mozilla.org/~fqueze2/webrtc/"></iframe><iframe
> src="https://people.mozilla.org/~fqueze2/webrtc/">
> 
> After step 6, I do get a microphone permission prompt, and can accept it.
> 
> I tried with both a Firefox 42.0 release, and a recent local build (built
> from up-to-date source yesterday).
> 
> Is there a step or a detail I could be missing?

I found a problem in the test you did above. Let me explain you.
1. Click audio on https://people.mozilla.org/~fqueze2/webrtc/ page
2. Ignore microphone share permission and keep it pending.
3. Click go back to main page.
At this step, please observe that as you change the page, the pending audio permission gets removed. Hence, there is no permission request in the queue. This would not reproduce the issue. I have other sample code where audio and video permission dialogs are generated on the same page. Can you provide me with your email address? I will provide you with my sample code.

Comment 5

[Florian Quèze [:florian]]

(In reply to rdaware from comment #4)
> (In reply to Florian Quèze [:florian] [:flo] from comment #3)

> > The page I used to attempt to reproduce is:
> > data:text/html,<iframe
> > src="https://people.mozilla.org/~fqueze2/webrtc/"></iframe><iframe
> > src="https://people.mozilla.org/~fqueze2/webrtc/">

> I found a problem in the test you did above. Let me explain you.
> 1. Click audio on https://people.mozilla.org/~fqueze2/webrtc/ page

The page I used is the whole data URL, this loads the test page twice in iframes.

> I have other sample code where audio and
> video permission dialogs are generated on the same page. Can you provide me
> with your email address? I will provide you with my sample code.

florian AT mozilla DOT com.

Comment 6

[rdaware]

(In reply to Florian Quèze [:florian] [:flo] from comment #5)
> (In reply to rdaware from comment #4)
> > (In reply to Florian Quèze [:florian] [:flo] from comment #3)
> 
> > > The page I used to attempt to reproduce is:
> > > data:text/html,<iframe
> > > src="https://people.mozilla.org/~fqueze2/webrtc/"></iframe><iframe
> > > src="https://people.mozilla.org/~fqueze2/webrtc/">
> 
> > I found a problem in the test you did above. Let me explain you.
> > 1. Click audio on https://people.mozilla.org/~fqueze2/webrtc/ page
> 
> The page I used is the whole data URL, this loads the test page twice in
> iframes.
> 
> > I have other sample code where audio and
> > video permission dialogs are generated on the same page. Can you provide me
> > with your email address? I will provide you with my sample code.
> 
> florian AT mozilla DOT com.

Thank you Florian. I have emailed sample code to you.

Comment 7

[Florian Quèze [:florian]]

Attachment: Reduced testcase

Rahul emailed me a testcase, which I reduced.

Steps to reproduce using this reduced test case:
1. Click the 'Start Audio' button.
2. Discard the audio permission prompt by clicking outside of it.
3. Click the 'Start Video' button.

Expected result: a video permission prompt appears.

Actual result: A "NotFoundError: The object can not be found here." error is passed immediately to the error callback (and printed to the browser console by the testcase).

Comment 8

[Florian Quèze [:florian]]

Using the reduced testcase I attached, I bisected and got this regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b6a79816ee715edba178fb7e93c91c9879c564b0&tochange=be765d7ba0ef7bbb12f99f099ff318040eafd7fc

The 2 bugs in the range that seem related are bug 1037389 and bug 1152381.

Comment 9

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

The problem is in platform code I introduced. Taking it.

Comment 10

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: MozReview Request: Bug 1224766 - forward callID to disambiguate multiple gUM requests from same window.

Review commit: https://reviewboard.mozilla.org/r/29965/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/29965/

Comment 11

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Comment on attachment 8705410 [details]
MozReview Request: Bug 1224766 - forward callID to disambiguate multiple gUM requests from same window.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/29965/diff/1-2/

Comment 12

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Fixed a B2G compile error on try.

Comment 13

[Florian Quèze [:florian]]

Would it be possible to have this case covered by automated tests?

Comment 14

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Would love to, but I don't know how to do that since it involves ContentWebRTC.jsm. Permission code is disabled for mochitests in the tree.

Comment 15

[Florian Quèze [:florian]]

Isn't the bug reproduced by calling twice navigator.mozGetUserMediaDevices; once audio-only and once video-only with the same window id?

Comment 16

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 8705410 [details]
MozReview Request: Bug 1224766 - forward callID to disambiguate multiple gUM requests from same window.

https://reviewboard.mozilla.org/r/29965/#review27203

Looks good - you'll likely need a DOM peer to rs it since the commit hook doesn't know if a webidl file is exposed to the web or not (IIRC)

Comment 17

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Florian Quèze [:florian] [:flo] from comment #15)
> Isn't the bug reproduced by calling twice navigator.mozGetUserMediaDevices;
> once audio-only and once video-only with the same window id?

Only if permission-code is enabled. The bug is in mozGetUserMediaDevices() which is only called in that case.

Comment 18

[Olli Pettay [:smaug][[e-mail]](vacation until July 14)]

Comment on attachment 8705410 [details]
MozReview Request: Bug 1224766 - forward callID to disambiguate multiple gUM requests from same window.

https://reviewboard.mozilla.org/r/29965/#review27295

ok, this is ChromeOnly, fine.

Comment 19

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/51900c5b53bd

Comment 20

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/51900c5b53bd

Comment 21

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Is there interest in uplifting this?

Comment 22

[rdaware]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #21)
> Is there interest in uplifting this?

Hi Jan-Ivar,

This is customer facing issue for our product. Hence, we need it to be in release as soon as possible. Is it possible to have it in the current beta version? Also, is there any way for me to test it?

Rahul

Comment 23

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

[Tracking Requested - why for this release]: See comment 22. Regression. Simple and safe fix.

Comment 24

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Rahul, please test in Firefox Nightly tomorrow, or to test it today,  you can try https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-99e44b0f28fc78f1b71243848515f2ff9e8a27bc/

Comment 25

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Comment on attachment 8705410 [details]
MozReview Request: Bug 1224766 - forward callID to disambiguate multiple gUM requests from same window.

Approval Request Comment
[Feature/regressing bug #]: Bug 1037389

[User impact if declined]:

On sites that request camera and microphone permission independently, the browser will fail to prompt the user for permission if the user has ignored a permission prompt of the other kind (camera vs microphone) on the same page, preventing access.

On sites that request camera and microphone permission independently yet do so at about the same time, the browser will fail to prompt the user for permission for one of them, preventing access.

Workaround: Refresh page, start over, and answer each prompt immediately as it appears, if possible, or choose "Always Allow".

[Describe test coverage new/current, TreeHerder]:

Landed on m-c today. Manually tested on OSX and Android.

[Risks and why]: 

Lack of automated tests (see comment 14). Otherwise low risk, as code change is mostly plumbing a piece of information (call-id) from JS to c++, to disambiguate multiple calls.

[String/UUID change made/needed]: none

Comment 26

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

I will wait for verification on this fix before taking it in Beta44.

Comment 27

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8705410 [details]
MozReview Request: Bug 1224766 - forward callID to disambiguate multiple gUM requests from same window.

Ritu will make the call for beta. But to me, this is too late in the 44 cycle.
We shipped two releases with this issue, I think I can wait.
Taking in aurora.

Comment 28

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8705410 [details]
MozReview Request: Bug 1224766 - forward callID to disambiguate multiple gUM requests from same window.

While as such this bug fix does not meet the Beta44 uplift as it isn't a recent regression. However, based on a chat with Maire, it seems this is a fix that Cisco really needs in Fx44 release version. Beta44+

Comment 29

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #24)
> Rahul, please test in Firefox Nightly tomorrow, or to test it today,  you
> can try
> https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-
> 99e44b0f28fc78f1b71243848515f2ff9e8a27bc/

Rahul, please drop a note here when you've verified that the original problem has been fixed (in case of discrepancy between comment 0 and comment 7). Thanks.

Comment 30

[rdaware]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #29)
> (In reply to Jan-Ivar Bruaroey [:jib] from comment #24)
> > Rahul, please test in Firefox Nightly tomorrow, or to test it today,  you
> > can try
> > https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-
> > 99e44b0f28fc78f1b71243848515f2ff9e8a27bc/
> 
> Rahul, please drop a note here when you've verified that the original
> problem has been fixed (in case of discrepancy between comment 0 and comment
> 7). Thanks.

I have verified this issue in Firefox Nightly. Marking it as verified. It would be great if I could know when it would be available in beta version. Thank you.

Comment 31

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: Reduced testcase

Added video and audio elements to test case to make testing easier.

Comment 32

[Randell Jesup [:jesup] (needinfo me)]

I've tested this pretty extensively; I can't find any regressions in a beta build with this patch applied.

Comment 33

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to rdaware from comment #30)
> (In reply to Jan-Ivar Bruaroey [:jib] from comment #29)
> > (In reply to Jan-Ivar Bruaroey [:jib] from comment #24)
> > > Rahul, please test in Firefox Nightly tomorrow, or to test it today,  you
> > > can try
> > > https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-
> > > 99e44b0f28fc78f1b71243848515f2ff9e8a27bc/
> > 
> > Rahul, please drop a note here when you've verified that the original
> > problem has been fixed (in case of discrepancy between comment 0 and comment
> > 7). Thanks.
> 
> I have verified this issue in Firefox Nightly. Marking it as verified. It
> would be great if I could know when it would be available in beta version.
> Thank you.

Rahul, this fix should be in 44.0b9 that will go live on beta channel around noon PST tomorrow (1/15/2016).

Comment 34

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d41f633eeaf6

Comment 35

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/releases/mozilla-beta/rev/60b64e5098dd

Comment 36

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Florin, would you be able to get your team to do some focused testing on this fix? Thanks!

Comment 37

[Andrei Vaida [:avaida]]

(In reply to Ritu Kothari (:ritu) from comment #36)
> Florin, would you be able to get your team to do some focused testing on
> this fix? Thanks!

Setting qe+; we'll make sure this gets tested on 44.0b9.

Comment 38

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/60b64e5098dd

Comment 39

[Bogdan Maris, Desktop QA]

Reproduced the initial issue using Firefox 42.0, verified that the issue is fixed using Firefox 44 beta 9, tinderbox Developer Edition 45.0a2 and latest Nightly 46.0a1 across platforms (Windows 7 64bit, Windows 10 64bit, Ubuntu 12.04 32bit and Mac OS X 10.10.5).