Closed Bug 1224766 Opened 4 years ago Closed 4 years ago

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

Categories

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

42 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla46
Tracking Status
firefox42 --- wontfix
firefox43 --- wontfix
firefox44 + verified
firefox45 + verified
firefox46 --- verified
b2g-v2.5 --- fixed
Blocking Flags:

People

(Reporter: rdaware, Assigned: jib)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

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
Severity: normal → blocker
Component: Untriaged → Device Permissions
OS: Unspecified → All
Priority: -- → P1
Hardware: Unspecified → All
This seems related to bug 861716.
Severity: blocker → normal
Priority: P1 → --
See Also: → 861716
(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
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?
(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.
(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.
(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.
Attached file Reduced testcase (obsolete) —
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).
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.
Status: UNCONFIRMED → NEW
Component: Device Permissions → WebRTC: Audio/Video
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
The problem is in platform code I introduced. Taking it.
Assignee: nobody → jib
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/
Fixed a B2G compile error on try.
Would it be possible to have this case covered by automated tests?
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.
Isn't the bug reproduced by calling twice navigator.mozGetUserMediaDevices; once audio-only and once video-only with the same window id?
backlog: --- → webrtc/webaudio+
Rank: 17
Priority: -- → P1
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)
Attachment #8705410 - Flags: review?(rjesup) → review+
Attachment #8705410 - Flags: review?(bugs)
(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 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.
Attachment #8705410 - Flags: review?(bugs) → review+
https://hg.mozilla.org/mozilla-central/rev/51900c5b53bd
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Is there interest in uplifting this?
Flags: needinfo?(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
Flags: needinfo?(rdaware)
[Tracking Requested - why for this release]: See comment 22. Regression. Simple and safe fix.
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
Attachment #8705410 - Flags: approval-mozilla-beta?
Attachment #8705410 - Flags: approval-mozilla-aurora?
I will wait for verification on this fix before taking it in Beta44.
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.
Attachment #8705410 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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+
Attachment #8705410 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(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/jbruaroey@mozilla.com-
> 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.
Flags: needinfo?(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/jbruaroey@mozilla.com-
> > 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.
Status: RESOLVED → VERIFIED
Flags: needinfo?(rdaware)
Attached file Reduced testcase
Added video and audio elements to test case to make testing easier.
Attachment #8704626 - Attachment is obsolete: true
I've tested this pretty extensively; I can't find any regressions in a beta build with this patch applied.
(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/jbruaroey@mozilla.com-
> > > 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).
Florin, would you be able to get your team to do some focused testing on this fix? Thanks!
Flags: needinfo?(florin.mezei)
(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.
Flags: needinfo?(florin.mezei) → needinfo?(andrei.vaida)
Flags: needinfo?(andrei.vaida) → qe-verify+
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).
Duplicate of this bug: 1238904
You need to log in before you can comment on or make changes to this bug.