Closed Bug 1609973 Opened 5 years ago Closed 5 years ago

getUserMedia({audio: true}) is broken in JSFiddle by feature policy landing

Categories

(Core :: DOM: Security, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla74
Tracking Status
firefox-esr68 --- unaffected
firefox72 --- unaffected
firefox73 + disabled
firefox74 + verified

People

(Reporter: jib, Assigned: johannh)

References

(Regression)

Details

(Keywords: regression, site-compat, Whiteboard: [domsecurity-backlog1])

Attachments

(1 file)

STRs:

  1. Open https://jsfiddle.net/jib1/59og5vhn/
audio.srcObject = await navigator.mediaDevices.getUserMedia({audio: true});

Expected result:

  • Prompt: "Will you allow jsfiddle.net to give fiddle.jshell.net access to your microphone?"

Actual result:

  • Nothing happens (no prompt, no audio).

Workaround:

  • adding , video: true to the constraints makes it work (prompts for both cam + mic)

Alternate STRs:

  1. Open https://jan-ivar.github.io/dummy/iframe_gum_starcross.html and click Microphone (Camera works)

Regression range:

20:16.98 INFO: Narrowed inbound regression window from [ebf5f725, 4fe02c65] (3 builds) to [ebf5f725, 195319ed] (2 builds) (~1 steps left)
20:16.98 INFO: No more inbound revisions, bisection finished.
20:16.98 INFO: Last good revision: ebf5f725d0b3268b3d2a96e58c02c7740b4653b2
20:16.98 INFO: First bad revision: 195319ed0bb4dca7ddbda206e74338ed92699715
20:16.98 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ebf5f725d0b3268b3d2a96e58c02c7740b4653b2&tochange=195319ed0bb4dca7ddbda206e74338ed92699715

[Tracking Requested - why for this release]: Regression in behavior on well-known site (JSFiddle). Prompt in question is new behavior being introduced, and we should catch it being broken while we can.

Keywords: site-compat

Thomas was affected by the layoffs so there's a good chance we won't get to fix this in time for 73. I could take a look but I'm really busy right now, leaving needinfo in case I get to it.

Not sure what that means for shipping FP, how bad is this outside of JSFiddle?

Flags: needinfo?(jhofmann)
Flags: needinfo?(jhofmann)
Flags: needinfo?(jhofmann)

We probably can't fix this for 73, we might have to disable Feature Policy for now (there have been other regressions).

Priority: -- → P3
Summary: getUserMedia({audio: true}) is broken in JSFiddle → getUserMedia({audio: true}) is broken in JSFiddle by feature policy landing
Whiteboard: [domsecurity-backlog1]

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

Priority: P3 → P1

Should be trivial to solve and uplift.

Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Flags: needinfo?(jhofmann)

Instead of correcting the string in the localization file, I use the slightly inconsistent
string in code now, to avoid issues with uplifting.

Pushed by jhofmann@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/89bd83783b10
Fix wrong localization string in WebRTCParent.js. r=nhnt11
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74

Feature Policy was disabled for Fx73 in bug 1610572, so 73.0b9+ shouldn't be affected by this bug anymore.

Flags: qe-verify+

Hmm, it looks like 73 is affected by this bug (spotted in bug 1611931). I can reproduce it in 73.0b11 with e.g. https://jsfiddle.net/jib1/n7bmkjnf

In browser console:

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.formatStringFromName]"
nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/browser.js :: 
getFormattedString :: line 603"  data: no] browser.js:603:27

Looks like this codepath is throwing regardless of feature policy? :-(

Ryan, is it too late to get this uplifted asap?

Flags: needinfo?(ryanvm)
Flags: needinfo?(jhofmann)

Ah, so the crashing codepath is not taken in Nightly, but it is in Beta, because I see in about:config of 73.0b11 that dom.security.featurePolicy.enabled is still true!

If @IS_EARLY_BETA_OR_EARLIER@ in https://hg.mozilla.org/releases/mozilla-beta/rev/808ea709938d means what I think it means, then it explains why beta is broken and why nightly is not and why release 73 would (hopefully?) not be broken once 73 beta cuts over to release...

But this seems wrong: Shouldn't we be beta-testing with feature policy off because that's what will go to release?

I can confirm this issue is fixed on the latest nightly, I verified using Windows 10 x64, macOS 10.14, macOS 10.13 and Ubuntu 18.04.

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #12)

Ah, so the crashing codepath is not taken in Nightly, but it is in Beta, because I see in about:config of 73.0b11 that dom.security.featurePolicy.enabled is still true!

If @IS_EARLY_BETA_OR_EARLIER@ in https://hg.mozilla.org/releases/mozilla-beta/rev/808ea709938d means what I think it means, then it explains why beta is broken and why nightly is not and why release 73 would (hopefully?) not be broken once 73 beta cuts over to release...

But this seems wrong: Shouldn't we be beta-testing with feature policy off because that's what will go to release?

I see that it is also set to true there:
https://searchfox.org/mozilla-beta/source/browser/app/profile/firefox.js#1711

Fixing over in 1610572...

Flags: needinfo?(ryanvm)
Flags: needinfo?(jhofmann)

73.0RC1 will have the follow-up fix from bug 1610572. Let's try to verify this bug again with that build once available.

I verified this fix using Fx 74.0b1 on Windows 10 x64, Ubuntu 18.04 and macOS 10.15.

Status: RESOLVED → VERIFIED
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: