Closed
Bug 1396542
Opened 7 years ago
Closed 7 years ago
Firefox 57 audio fails on some Linux machines; needs read access to /var/lib/dbus/machine-id
Categories
(Core :: Audio/Video: cubeb, defect, P2)
Core
Audio/Video: cubeb
Tracking
()
VERIFIED
FIXED
mozilla58
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox55 | --- | unaffected |
firefox56 | --- | unaffected |
firefox57 | + | verified |
firefox58 | --- | verified |
People
(Reporter: phoglund, Assigned: jld, NeedInfo)
References
Details
(Keywords: regression, Whiteboard: [sb+])
Attachments
(6 files, 3 obsolete files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Steps to reproduce:
Go to www.apprtc.appspot.com/r/someroomname in Chrome on another machine (I used Chrome 60.0.3112.101 in this case, but Chrome version doesn't appear to matter). Then go to the same address in Firefox Nightly 57.0a1 (2017-09-03) (64-bit).
Repros 100%.
Actual results:
The AppRTC call doesn't establish.
Expected results:
The call should establish (e.g. the video feed from the remote browser should be shown, and vice versa).
Works in Firefox 56.0a1 (2017-07-21) (64-bit), so this must have regressed fairly recently. Not sure if this is a WebRTC error or a more mundane error. Attaching the javascript log from a successful run and a failed run.
Reporter | ||
Comment 1•7 years ago
|
||
Comment 2•7 years ago
|
||
[Tracking Requested - why for this release]: May be a major regression in WebRTC
Updated•7 years ago
|
Component: Untriaged → WebRTC
Product: Firefox → Core
Comment 3•7 years ago
|
||
Can you please use this tool to determine the regression range? https://mozilla.github.io/mozregression/
From command line:
> mozregression --good 56 --bad 57
Keywords: regression,
regressionwindow-wanted
Comment 4•7 years ago
|
||
I just tried to repro locally with a single machine only, but everything works as expected. I'll try to repro tomorrow with two machines.
Flags: needinfo?(drno)
Reporter | ||
Comment 5•7 years ago
|
||
Re #4: I tried reproing on my linux machine, and I can repro on a single machine as well (I just had to pass --use-fake-device-for-media-stream to Chrome since I only have one webcam).
Nils: you are connecting chrome-to-firefox, right, and not firefox-to-firefox?
Reporter | ||
Comment 6•7 years ago
|
||
Re #3: Running your command gives: 0:01.11 ERROR: The url 'https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=56' contains no pushlog. Maybe use another range ?
I did run mozregression --good 2017-07-21 --bad 2017-09-03 instead. It looks like this happened between the 2017-07-24 and 2017-07-25 nightlies.
I kept bisecting and this is the final result (I'll attach the full bisect log).
13:21.72 INFO: No more inbound revisions, bisection finished.
13:21.72 INFO: Last good revision: 8e1e06adf80f82d3d5cf08eadaf569a107bd1ecf
13:21.72 INFO: First bad revision: b5fa08551d6e74d8300fa94f3161afdffd867764
13:21.72 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8e1e06adf80f82d3d5cf08eadaf569a107bd1ecf&tochange=b5fa08551d6e74d8300fa94f3161afdffd867764
Reporter | ||
Comment 7•7 years ago
|
||
Reporter | ||
Comment 8•7 years ago
|
||
It's interesting that the implicated patches are Linux-specific, so this could be a linux-only problem. Which platform were you on in #4, Nils?
Comment 9•7 years ago
|
||
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Firefox: 57.0a1, Build ID: 20170904220027
I have tested this issue on latest Firefox release (55.0.3) and latest Nightly (57.0a1) build and could not reproduce it.
I've navigated to the provided URL, but the connection to the website is unsecure (NET::ERR_CERT_COMMON_NAME_INVALID).
Instead of the provided URL, I've used https://appr.tc with 3 different machines to test this issue, one with Win 10, a Mac 10.12 and an Ubuntu 16.04, and everything works as expected.
status-firefox56:
? → ---
status-firefox57:
? → ---
Reporter | ||
Comment 10•7 years ago
|
||
Re #9: Ok, which Chrome version did you use?
Comment 11•7 years ago
|
||
Version 60.0.3112.113 (Official Build) (64-bit)
Reporter | ||
Comment 12•7 years ago
|
||
Ok, just to ensure we agree what "works as expected" means. The page should load, the video feeds make a flip-over animation and the feed from the other machine starts playing. There are two video tags on the page, one local preview and one remote view. Is that what you're seeing Marius?
Comment 13•7 years ago
|
||
Yes, the page loads, video feed makes a flip-over animation when the other party joins/connects, there are two video tags on the page (you are on the bottom right corner and the other party is displayed on the screen).
Could you please post all the information from the about:support page?
Also, have you also tried to reproduce on https://appr.tc? I could only manage to get a call working on this page.
Flags: needinfo?(phoglund)
Comment 14•7 years ago
|
||
FYI, from Chrome: (Linux, Version 60.0.3112.113 (Official Build) (64-bit)) trying to connect to: www.apprtc.appspot.com/r/jesup
Your connection is not private
Attackers might be trying to steal your information from www.apprtc.appspot.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
Trying appr.tc/r/jesup: no problems, with Firefox Nightly on Windows or Linux. I was using e10s (multi-process) in Firefox (since the commits flagged above have to do with sandboxing.
What exact OS are you using? and what audio devices?
Comment 15•7 years ago
|
||
Yesterday I was trying on Mac only. Today I tried on Fx on Mac and Chrome 60 on Win 10.
Again I can't repro either. I tried:
- with both machines on the same LAN
- with both machines in different LAN so they ended up using TURN servers
- from Fx to Chrome
- from Chrome to Fx
All works fine. You briefly see your own video. Then then video flips over and you start to see the video from the other side and your own preview in the lower right corner.
I also encountered the TLS cert problem with www.apprtc.apspot.com.
Patrik: do you have any more details on what is actually not working? Is the ICE connection not getting established? Is the video not playing? Could you please attach a copy of "about:webrtc" from Firefox from such a failed call?
Flags: needinfo?(drno)
Reporter | ||
Comment 16•7 years ago
|
||
Flags: needinfo?(phoglund)
Reporter | ||
Comment 17•7 years ago
|
||
Re #13: I've run on apprtc.appspot.com, but appr.tc is just an alias for that right? It's the same page.
Re #14: Thanks, noted. I'm running Ubuntu 14.04 trusty. I have a GF108 High Definition Audio Controller Digital Stereo (HDMI) in this machine.
Re #15: Chrome says ICE is completed. The firefox side says "End of candidates" from apprtc.debug.js when a call succeeds (like when I run on my mac), and it does _not_ say that for a failing call on my Linux box. Here is the code that says that: https://github.com/webrtc/apprtc/blob/1bf0f49c731715bd9c4f53b41df37525e670ee3f/src/web_app/js/peerconnectionclient.js#L329 I'm not good enough at WebRTC call debugging to know what this means. Anyway, AppRTC flips the video tags when the remote video's ready state is at least 2 (see https://github.com/webrtc/apprtc/blob/cf63a6f65badbf2cb38382271bbe2486c66b2958/src/web_app/js/appcontroller.js#L276), i.e. video bits have started arriving. Something fails before that.
Reporter | ||
Comment 18•7 years ago
|
||
I've made another finding: I can't get a call up even when I call from my working firefox nightly on mac to my nightly on Linux. Therefore, this isn't an interop bug between Chrome and Firefox. We should rename this bug to "Firefox nightly WebRTC doesn't work on certain Linux machines" or something like that :)
Updated•7 years ago
|
Attachment #8904891 -
Attachment is obsolete: true
Comment 19•7 years ago
|
||
I found one indicator in Patrik's logs: Firefox SDP shows in the audio part only a=recvonly, which I guess means gUM failed to get the mic. As the video m-section contains a=sendrecv this appears to be an audio only problem on Linux.
Paul: what kind of log files would we need from Patrik to find out what is going on here?
Flags: needinfo?(padenot)
Summary: Firefox and Chrome fail to set up WebRTC call on AppRTC; regressed sometime the past few weeks. → Firefox 57 audio fails on some Linux machines
Comment 20•7 years ago
|
||
Please activate flags: cubeb:4,MediaStreamGraph:4,MediaManager:4
Flags: needinfo?(padenot)
Comment 21•7 years ago
|
||
I'm not sure audio is at fault here. An audio issue would most likely manifest itself as a fail-to-start (gUM rejected) or a started-but-no-callbacks (gUM stalled). Here gUM must have been resolved since apprtc proceeded to setting up the connection. A gUM reject on apprtc can't be missed.
Nils, what do you look at when deciding to make it recvonly? MediaStreamTracks?
Flags: needinfo?(drno)
Updated•7 years ago
|
Whiteboard: [needinfo 2017-09-07 drno]
Reporter | ||
Comment 22•7 years ago
|
||
Aha! Yeah, that's the difference. When I run on Linux it doesn't ask for mic, only webcam, but when I run on mac it asks for both mic and webcam. So that suggests it doesn't recognize my mic. At least not after the three patches I bisected down to in #6. So that's why the call isn't getting up, because AppRTC doesn't handle that?
It doesn't recognize either the mic in my webcam or the front built-in audio. I can see they are working in the OS though.
Reporter | ||
Comment 23•7 years ago
|
||
Re #20: Can you explain in detail how to activate the flags? I found cubeb in about:config but not the other two.
Comment 24•7 years ago
|
||
Aha, maybe apprtc does an enumeration pass before deciding what to ask for -- and only ask for video when no audio devices were found.
See [1] for info on enabling logging. TL;DR set some environment variables when running firefox, like
> MOZ_LOG=timestamp,cubeb:4,MediaStreamGraph:4,MediaManager:4 MOZ_LOG_FILE=/tmp/moz.log ./firefox
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Gecko_Logging#Enabling_Logging
Comment 25•7 years ago
|
||
(In reply to Andreas Pehrson [:pehrsons] from comment #21)
> Nils, what do you look at when deciding to make it recvonly?
> MediaStreamTracks?
The SDP in the logs which Patrik send to me show a=recvonly for the audio m-section, a=sendrecv for the video m-section. So I think appr.tc failed to attach an audio track to the PC. How would gUM behave if audio and video got requested, but only video succeeded?
Flags: needinfo?(drno)
Comment 26•7 years ago
|
||
(In reply to Patrik Höglund from comment #22)
> Aha! Yeah, that's the difference. When I run on Linux it doesn't ask for
> mic, only webcam, but when I run on mac it asks for both mic and webcam. So
> that suggests it doesn't recognize my mic. At least not after the three
> patches I bisected down to in #6. So that's why the call isn't getting up,
> because AppRTC doesn't handle that?
Not sure about the current state. But historically AppRTC did not handle it very well when it requests audio and video, but only got one of these.
Reporter | ||
Comment 27•7 years ago
|
||
Log from failed apprtc call. with
MOZ_LOG=timestamp,cubeb:4,MediaStreamGraph:4,MediaManager:4 MOZ_LOG_FILE=/tmp/moz.log ./firefox-nightly/firefox_aug31/firefox
Reporter | ||
Comment 28•7 years ago
|
||
Re #24: attached moz.log. I only managed to get one out on the first attempt though: when I tried again, all I get is empty logs!
Updated•7 years ago
|
Attachment #8906506 -
Attachment mime type: text/x-log → text/plain
Comment 29•7 years ago
|
||
(In reply to Nils Ohlmeier [:drno] from comment #25)
> How would gUM behave if audio and video got requested, but only video succeeded?
We have been rejecting the entire request in that case for quite some time, per the spec.
Comment 30•7 years ago
|
||
(In reply to Patrik Höglund from comment #27)
> Created attachment 8906506 [details]
> moz.log
>
> Log from failed apprtc call. with
>
> MOZ_LOG=timestamp,cubeb:4,MediaStreamGraph:4,MediaManager:4
> MOZ_LOG_FILE=/tmp/moz.log ./firefox-nightly/firefox_aug31/firefox
I don't see cubeb or media logs here. This could be from the parent process, while media logs are in the child process. Those logs should appear in the same location but under other file names that indicate which process they came from. It could be that they cannot be written due to sandboxing. That can be lowered per the logging wiki page I linked in comment 24.
Alternatively turn off multi-process firefox in about:preferences and all you get is one file.
Reporter | ||
Comment 31•7 years ago
|
||
I found a /tmp/moz.log.child-1 which has cubeb lines in it, attaching that.
Another data point: When I turn multi-process off, the call works!
Reporter | ||
Comment 32•7 years ago
|
||
Log from child process with failing call
Comment 33•7 years ago
|
||
Failure of audio on Linux with e10s is very likely a sandboxing issue - Likely the sandboxwas tightened, and (your?) Pulse accesses some files which may not be whitelisted.
What OS version are you running on? Anything non-standard, or non-standard settings? Unusual audio drivers?
I'll get info on how to log sandbox violations.
Flags: needinfo?(phoglund)
Comment 34•7 years ago
|
||
:gcp fyi this bug looks like sandbox related breakage on linux, maybe you can help with comment 33?
Flags: needinfo?(gpascutto)
Comment 35•7 years ago
|
||
Tracking for 57, from what I understand the tightened linux sandbox might ship there.
status-firefox55:
--- → unaffected
status-firefox56:
--- → unaffected
status-firefox57:
--- → affected
Comment 36•7 years ago
|
||
Patrik - can you do a run (with e10s (multiprocess) on), with env variable MOZ_SANDBOX_LOGGING set (I presume setting it to '1' is sufficient). Thanks!
Reporter | ||
Comment 38•7 years ago
|
||
mozlog from latest run
Attachment #8906506 -
Attachment is obsolete: true
Attachment #8906600 -
Attachment is obsolete: true
Reporter | ||
Comment 39•7 years ago
|
||
Re #36: setting the env variable caused Sandbox lines to be printed on stdout/stderr, so I assume those are the ones you want. I also attached the child-1 log from the same run if you need it.
Comment 40•7 years ago
|
||
Changing the component to cubeb, this is clearly a cubeb issue. Cubeb is our cross-platform audio input output library.
Component: WebRTC → Audio/Video: cubeb
Comment 41•7 years ago
|
||
Which Linux distribution is this? PulseAudio is probably failing to connect to the server. We have several specific holes for letting it figure out where to connect, but whatever PulseAudio version/config is used here seems to be using another method which is blocked.
Flags: needinfo?(gpascutto) → needinfo?(phoglund)
Keywords: regressionwindow-wanted
Whiteboard: [needinfo 2017-09-07 drno] → [needinfo 2017-09-07 drno],sb?
Comment 42•7 years ago
|
||
This is weird:
Sandbox: Failed errno -13 op 0 flags 02400000 path /dev/shm/pulse-shm-3626393402
/dev/shm is whitelisted even for writing:
https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp#48
Is it the flags? 02400000
Comment 43•7 years ago
|
||
The flags are
O_NOFOLLOW 00400000
O_CLOEXEC 02000000
We allow those, so that shouldn't be the problem:
https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/security/sandbox/linux/broker/SandboxBroker.cpp#444
Reporter | ||
Comment 44•7 years ago
|
||
Since there are a few new people in the bug, let me remind you that I bisected this issue in #6 and it boiled down to three possible culprits: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8e1e06adf80f82d3d5cf08eadaf569a107bd1ecf&tochange=b5fa08551d6e74d8300fa94f3161afdffd867764
The distribution is Goobuntu. I have no idea how it differs from Ubuntu unfortunately.
Flags: needinfo?(phoglund)
Comment 45•7 years ago
|
||
Something interesting is this:
Normal refuses will look like this:
Sandbox: SandboxBroker: denied op=open rflags=2000000 perms=0 path=/var/lib/dbus/machine-id for pid=568
Sandbox: Failed errno -13 op 0 flags 02000000 path /var/lib/dbus/machine-id
Logging the error in the SandboxBroker and SandboxBrokerClient
However the shm fails:
Sandbox: Failed errno -13 op 0 flags 02400000 path /dev/shm/pulse-shm-3626393402
Seem to fail in a way that the Broker doesn't log them.
Comment 46•7 years ago
|
||
(In reply to Patrik Höglund from comment #44)
> Since there are a few new people in the bug, let me remind you that I
> bisected this issue in #6 and it boiled down to three possible culprits:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=8e1e06adf80f82d3d5cf08eadaf569a107bd1ecf&tochange=b5fa
> 08551d6e74d8300fa94f3161afdffd867764
I already removed the regression-window wanted flag because I saw that. Those 3 patches enable sandboxing of filesystem reads. We have no plans to back those out, so we'll have to figure out why PulseAudio is getting blocked by it. There's several specific holes to let it through until most of bug 1362220 lands.
> The distribution is Goobuntu. I have no idea how it differs from Ubuntu unfortunately.
Ouch, that will complicate matters.
Comment 47•7 years ago
|
||
Is it possible to run Firefox with the sandbox logging, look for the /dev/shm/pulse-shm-xxxxx refusal as in comment 45, and check what the actual permissions on that file are?
This logging is consistent with this open() failing:
https://dxr.mozilla.org/mozilla-central/rev/f9a5e9ed62103c84e4cde915f4d08f1ce71be83e/security/sandbox/linux/broker/SandboxBroker.cpp#725
Maybe we're not supposed to be able to open this at all, and we're only falling back to this because another way of connecting to Pulse was blocked earlier.
Assignee | ||
Comment 48•7 years ago
|
||
It looks like nobody's mentioned this line from the log yet:
Sandbox: SandboxBroker: denied op=open rflags=2000000 perms=0 path=/usr/local/xyz/home/phoglund/.pulse/client.conf for pid=568
If that file exists, that might be part of the cause.
Comment 49•7 years ago
|
||
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #48)
> It looks like nobody's mentioned this line from the log yet:
>
> Sandbox: SandboxBroker: denied op=open rflags=2000000 perms=0
> path=/usr/local/xyz/home/phoglund/.pulse/client.conf for pid=568
>
> If that file exists, that might be part of the cause.
I saw this, but as I understand .pulse is an older location, and now it's XDG_CONFIG_HOME, which is .config, which we cover. My Ubuntu 16.04 seems to have the PA stuff there indeed. So unless Goobuntu for some reason uses the older location, that should be fine.
Comment 50•7 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #49)
> I saw this, but as I understand .pulse is an older location, and now it's
> XDG_CONFIG_HOME, which is .config, which we cover.
https://dxr.mozilla.org/mozilla-central/source/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp#133
We should probably use XDG_CONFIG_HOME instead of .config, or both. I'll file that separately.
Reporter | ||
Comment 51•7 years ago
|
||
Re #49: I don't have a ~/.pulse dir, but I do have a ~/.config/pulse dir:
$ ls ~/.config/pulse/
7855a8131f74d443df3b71ef59a3d3ff-card-database.tdb 7855a8131f74d443df3b71ef59a3d3ff-device-volumes.tdb
7855a8131f74d443df3b71ef59a3d3ff-default-sink 7855a8131f74d443df3b71ef59a3d3ff-stream-volumes.tdb
7855a8131f74d443df3b71ef59a3d3ff-default-source cookie
Reporter | ||
Comment 53•7 years ago
|
||
Re #52:
All the /dev/shm/pulse-shm-* files have -rwx------.
Flags: needinfo?(phoglund)
Comment 54•7 years ago
|
||
(In reply to Patrik Höglund from comment #53)
> Re #52:
>
> All the /dev/shm/pulse-shm-* files have -rwx------.
Yes, but owned by what user/group?
Reporter | ||
Comment 55•7 years ago
|
||
All are owned by phoglund and group "eng", except for one which is owned by user lightdm and group lightdm.
Updated•7 years ago
|
Whiteboard: [needinfo 2017-09-07 drno],sb? → [needinfo 2017-09-07 drno][sb?]
Assignee | ||
Comment 56•7 years ago
|
||
I wondered if this might be related — /etc/machine-id doesn't exist, and /var/lib/dbus/machine-id isn't allowed by policy:
Sandbox: Failed errno -2 op 0 flags 02000000 path /etc/machine-id
Sandbox: SandboxBroker: denied op=open rflags=2000000 perms=0 path=/var/lib/dbus/machine-id for pid=568
That doesn't happen for me with regular WebAudio, because we start the audio backend before sandboxing[1], but it does with WebRTC, probably because of the unused extra PA instance it creates (bug 1394163). This suggests a possible test on Goobuntu: adding /var/lib/dbus/machine-id to the security.sandbox.content.read_path_whitelist pref (it's a comma-separated list of paths, but this should be the only item).
However, on plain Ubuntu 16.04, even if I remove /etc/machine-id I can't reproduce this using the instructions in comment #0. So that might not be it.
There's also this oddity, which also turned up in bug 1363378; we're returning EACCES instead of ENOENT for opening the empty string, which may or may not affect anything because we don't yet know what's doing that:
Sandbox: rewriting /proc/self/exe -> /proc/568/exe
Sandbox: Recording mapping /usr/local/xyz/home/phoglund/dev/chromium/firefox-nightly/firefox/firefox -> /proc/568/exe
Sandbox: SandboxBroker: denied op=open rflags=0 perms=0 path= for pid=568
Sandbox: Failed errno -13 op 0 flags 00 path
Sandbox: SandboxBroker: denied op=open rflags=0 perms=0 path= for pid=568
Sandbox: Failed errno -13 op 0 flags 00 path
And then there's this:
Sandbox: SandboxBroker: denied op=access rflags=4 perms=0 path=/proc/net for pid=568
Sandbox: Failed errno -13 op 1 flags 04 path /proc/net
My guess is that this is glibc's internal function __opensock, called from if_indextoname or similar, and bug 1384292 might be related, but from looking at the glibc source it should be harmless to deny access.
[1] https://searchfox.org/mozilla-central/rev/6326724982c66aaeaf70bb7c7ee170f7a38ca226/dom/ipc/ContentChild.cpp#1654
Reporter | ||
Comment 57•7 years ago
|
||
Re #56: adding /var/lib/dbus/machine-id to the security.sandbox.content.read_path_whitelist fixes the error.
Updated•7 years ago
|
Rank: 15
Priority: -- → P2
Whiteboard: [needinfo 2017-09-07 drno][sb?] → [sb?]
Assignee | ||
Comment 58•7 years ago
|
||
Bug 1388545 comment #6 seems to be the same problem on other distributions (including Ubuntu 14.04 but not Ubuntu 16.04, which might hint at why Goobuntu is affected). I'll just take this bug, because it should be a one-line fix.
Assignee: nobody → jld
Summary: Firefox 57 audio fails on some Linux machines → Firefox 57 audio fails on some Linux machines; needs read access to /var/lib/dbus/machine-id
Comment hidden (mozreview-request) |
Comment 60•7 years ago
|
||
mozreview-review |
Comment on attachment 8910529 [details]
Bug 1396542 - Let sandboxed content processes read /var/lib/dbus/machine-id.
https://reviewboard.mozilla.org/r/181962/#review187506
Didn't we have some meta to hang up the hundreds of PA related bugs on so we know what stuff to back out when it gets remoted? Maybe we should.
Attachment #8910529 -
Flags: review?(gpascutto) → review+
Assignee | ||
Comment 61•7 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #60)
> Comment on attachment 8910529 [details]
> Bug 1396542 - Let sandboxed content processes read /var/lib/dbus/machine-id.
>
> https://reviewboard.mozilla.org/r/181962/#review187506
>
> Didn't we have some meta to hang up the hundreds of PA related bugs on so we
> know what stuff to back out when it gets remoted? Maybe we should.
There's bug 1104619 (sb-audio), but I thought that was for things we plan to do, not things we plan to back out. I could file another bug for this, but that doesn't really seem useful if I'm just going to rip out all the #ifdef MOZ_PULSEAUDIO things at once.
Updated•7 years ago
|
Whiteboard: [sb?] → [sb+]
Comment 62•7 years ago
|
||
Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d095506bd1d6
Let sandboxed content processes read /var/lib/dbus/machine-id. r=gcp
Reporter | ||
Comment 63•7 years ago
|
||
Splendid! When will this fix make it Nightly, so I can re-enable the Chrome-Firefox interop test?
Comment 64•7 years ago
|
||
(In reply to Patrik Höglund from comment #63)
> Splendid! When will this fix make it Nightly, so I can re-enable the
> Chrome-Firefox interop test?
~12 hours after there is comment here from Pulsebot about mozilla-central.
We just switched to Firefox 58 so that might be some of the delay.
Comment 65•7 years ago
|
||
Actually this is in nightly now.
https://hg.mozilla.org/mozilla-central/rev/d095506bd1d6
Seems that merge wasn't marked in bugzilla?
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox58:
--- → fixed
Flags: needinfo?(wkocher)
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Comment 66•7 years ago
|
||
It seems that we want to uplift that in 57, Jed, could you fill an uplift request? Thanks
Flags: needinfo?(jld)
Comment 67•7 years ago
|
||
Comment on attachment 8910529 [details]
Bug 1396542 - Let sandboxed content processes read /var/lib/dbus/machine-id.
Approval Request Comment
[Feature/Bug causing the regression]: Bug 1308400
[User impact if declined]: No sound for some Linux distributions
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: No
[Needs manual test from QE? If yes, steps to reproduce]: Would be nice. Manual QA team found the bug.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No
[Why is the change risky/not risky?]: Addition to whitelist.
[String changes made/needed]: N/A
Flags: needinfo?(jld)
Attachment #8910529 -
Flags: approval-mozilla-beta?
Comment 68•7 years ago
|
||
Comment on attachment 8910529 [details]
Bug 1396542 - Let sandboxed content processes read /var/lib/dbus/machine-id.
A browser without sound is a bit sad, taking it to beta.
Should be in 57beta3
Attachment #8910529 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 69•7 years ago
|
||
bugherder |
Comment 70•7 years ago
|
||
(In reply to Sylvestre Ledru [:sylvestre] from comment #68)
> Comment on attachment 8910529 [details]
> Bug 1396542 - Let sandboxed content processes read /var/lib/dbus/machine-id.
>
> A browser without sound is a bit sad, taking it to beta.
> Should be in 57beta3
Beta is fine due to bug 1388046, which I am going to back out (in a new bug, I guess) right about now!
Comment 71•7 years ago
|
||
bugherder uplift |
(In reply to Julien Cristau [:jcristau] from comment #65)
> Seems that merge wasn't marked in bugzilla?
Weird, could've sworn I ran Bugherder on that merge push to mark all of the bugs in the push, but apparently I didn't. Sorry about that. Looks like Aryx got it, though.
Flags: needinfo?(wkocher)
Updated•7 years ago
|
status-firefox-esr52:
--- → unaffected
Updated•7 years ago
|
Flags: qe-verify+
Comment 73•7 years ago
|
||
I couldn't reproduce the bug and we tested on three different machines. We tried to make a call between Windows 10 (Chrome)and Windows 10 (Nightly from 2017-09-03), Windows 10 (Chrome) and Ubuntu 16.04 x64 (Nightly from 2017-09-03), mac 10.13 (Chrome) and Ubuntu 16.04 x64 (Nightly from 2017-09-03).
We tested using this https://appr.tc/r/jesup from comment 14, because the others didn't work. Using this link we managed to make a call without any problems.
Since we cannot reproduce this bug can you please verify it on Beta 57.0b14? So we can close this bug as verified fixed.
Thank you.
Flags: needinfo?(phoglund)
Assignee | ||
Comment 74•7 years ago
|
||
(In reply to Oana Botisan from comment #73)
> I couldn't reproduce the bug and we tested on three different machines. We
> tried to make a call between Windows 10 (Chrome)and Windows 10 (Nightly from
> 2017-09-03), Windows 10 (Chrome) and Ubuntu 16.04 x64 (Nightly from
> 2017-09-03), mac 10.13 (Chrome) and Ubuntu 16.04 x64 (Nightly from
> 2017-09-03).
This bug affects Ubuntu 14.04 but not 16.04; see bug 1388545 comment #6 and 7 (and comment #17 on this bug).
Comment 75•7 years ago
|
||
We managed to reproduce the bug using the method from https://bugzilla.mozilla.org/show_bug.cgi?id=1388545#c6 on Ubuntu 14.04 x32 on an older version of Nightly (2017-09-04).
We retested everything using the latest Nightly 58.0a1 and Firefox 57.0 - build 4 on the same platform, but the bug was not reproducing anymore.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in
before you can comment on or make changes to this bug.
Description
•