Closed Bug 1625508 Opened 5 months ago Closed 5 months ago

[Win] Installing the build in another location than the Program Files folder causes webrtc calls through sandbox process isolation to fail

Categories

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

76 Branch
All
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla76
Tracking Status
firefox-esr68 --- unaffected
firefox74 --- unaffected
firefox75 --- unaffected
firefox76 + verified

People

(Reporter: bogdan_maris, Assigned: bobowen)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Affected versions

  • Latest Nightly 76.0a1

Unaffected versions

  • Firefox 75.0b10
  • Firefox 74.0

Affected platforms

  • Windows 10 64bit

Unaffected platforms

  • macOS 10.15
  • Ubuntu 18.04 64bit

Steps to reproduce

  1. Visit https://hangouts.google.com/ or https://www.roundee.io/
  2. Join a room and allow the website to use the microphone (and camera if you have one, I did not)
  3. Microphone does not work (I only could determine this if more then 1 person was in that call).

Expected result

  • Microphone works without issues.

Actual result

  • Microphone does not work.

Regression range

Additional notes

  • I used a jack powered earphone with a splitter for audio and mic connectors.
  • I set the severity to Critical keeping in mind all that's happening now with Covid-19 and how many people are expected to use conferences. Plus we are late in the cycle, having this in beta will impact more users.
  • Other services could be also affected by this issue.
Flags: needinfo?(bobowencode)
Has Regression Range: --- → yes
Has STR: --- → yes

I don't seem to be able to reproduce this, is there anything unusual about your installation?

Flags: needinfo?(bobowencode) → needinfo?(bogdan.maris)
Attached image Image

I could not reproduce on the demo pages from comment 2, you can see the bug by accessing the following demo room I created https://www.roundee.io/testfirefox You can see the issue on the page before actually entering the room where it displays the devices that will be used in the call (Before you star - I've attached an image of the page). I only have the earphones connected to my PC (no other devices that have mic). Works fine on Chrome with the same setup.
If you are asked for an email when entering that room, just enter a dummy email, it should let you go further.

Flags: needinfo?(bogdan.maris) → needinfo?(bobowencode)

https://www.roundee.io/testfirefox seems to be working for me.
There is video and I can see the microphone meter moving.

Is there anything unusual about your installation?
For example, is your Firefox installed in the normal place (i.e. C:\Program Files) or do you have a different installation dir?

Flags: needinfo?(bobowencode) → needinfo?(bogdan.maris)

Actually I had Latest Nightly unziped on Desktop. I installed it the default location afterwards and it looks that it works from Program Files. I didn't even noticed that to be honest, have multiple Browsers on my PC.

Flags: needinfo?(bogdan.maris)
Priority: -- → P2
Duplicate of this bug: 1625872

Marked bug 1625872 as a duplicate of this as the earlier bug, but I've copied over its description.

Assignee: nobody → bobowencode
Status: NEW → ASSIGNED
Priority: P2 → P1
Summary: [Win] Microphone is not working on hangouts and roundee with latest Nightly → [Win] Installing the build in another location than the Program Files folder causes webrtc calls through sandbox process isolation to fail
Duplicate of this bug: 1625424

Add rule to allow content processes to duplicate named pipes to other child
processes. This is why SetLockdownDefaultDacl wasn't working before because it
broke the local handle duplication.
This also reverts the change that was using USER_LIMITED from the start of the
process because that breaks DLL loading when installed somewhere that relies on
the user's own SID for access.

Pushed by bobowencode@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/9ed101ef9d22
Use SetLockdownDefaultDacl for the socket process. r=handyman
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76

Thanks for the fast Fix! Verified that the issue is not reproducible anymore using the latest Nightly 76.0a1.

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