GNOME Bugzilla – Bug 675217
Epiphany sets sound volume to 100%
Last modified: 2018-01-23 17:55:49 UTC
Severity is set to critical because of possible permanent hearing damage to the user. To reproduce, install pulseaudio and GNOME. While installing pulseaudio, ensure that you have Flat Volumes enabled (this is the case by default except if you are using Ubuntu). Then: 1. Turn the sound volume low (I generally have to do that because of rather sensitive headphones) 2. Start epiphany, visit http://www.fungamescool.com/FunWithDynamite/fun-with-dynamite.html 3. Place a dynamite stick, click to explode the bad guy Expected result: the game produces an explosion sound at the volume that I set at step 1. Actual result: an explosion sound at 100% hardware volume. My own opinion is that it is a bug in pulseaudio (see http://pulseaudio.org/ticket/774 and https://bugs.freedesktop.org/show_bug.cgi?id=46466 and possible other duplicates), but, given that upstream doesn't fix it for years, it has to be fixed in all clients by never touching the mixer (it is unusable, because of the different semantics with and without flat volumes and no way to detect whether they are in effect).
(In reply to comment #0) > Severity is set to critical because of possible permanent hearing damage to the > user. If you can get "permanent hearing damage" by having your volume set at 100% you should probably sue your hardware manufacturer, you'll make a ton of money! As for the rest I believe this is basically a WebKit issue, pinging the media experts on there to have a look.
I can reproduce this bug, might be related to bug 680779 according to Alexander.
I experience this running rdio.com within epiphany-3.8.2-1.fc19 and webkitgtk3-2.0.3-1.fc19
*** Bug 696317 has been marked as a duplicate of this bug. ***
Is this the bug fixed by WebKitGTK+ 2.1.91? From the changelog: "Fix the media player to not set the system volume to 100%."
I will retest the bug later today. However, I have read the patch that led to this changelog entry, and think that it does not fix the underlying issue at all. If the "fun with dynamite" testcase no longer demonstrates the bug, I will try to construct another one. Please close the bug if I don't provide further information within 48 hours.
Not fixed. The "Fun with dynamite" testcase still works.
A more self-contained testcase, suggested by a colleague, is at http://jsfiddle.net/bteam/FbkGD/ . The crux of the bug is that there are non-user-initiated volume changes, and webkit fails to properly virtualize the application-set volume.
First, I disagree with bug 696317 being a 100% exact duplicate of this bug. This bug is about a webpage explicitly setting the volume to 100% (look for "var C=this;this.volume=1;this.mutevol=1" in http://www.mikanse.com/FunWithDynamite/funwithdynamite.js), expecting the relative model. That bug is about the defsult audio/video volume being 100% in Webkit, if an application doesn't touch it. That bug is fixed, this one isn't. Second, I have discussed this during LinuxCon Europe 2013 in person. As a result, I think that it would be wrong to keep this bug open in Gnome bugzilla without discussion. This is why I think so: 1. The bug has nothing to do with Epiphany itself. In other words, there is nothing related to audio volumes that can be changed or needs to be changed in the Epiphany code. All the responsibility is totally with WebKit-GTK and/or PulseAudio. 2. Some people (including Lennart Poettering, Arun Raghavan, Xabier Rodríguez Calvar) think that this "100% hardware volume explosion" is not a bug at all, or maybe a bug in the web page. But I strongly disagree. 3. PulseAudio developers say that it is either not a bug or only a sandboxing issue in WebKit and should be fixed on WebKit side. It is defined that in flat-volume mode each application controls the absolute volume of its stream. 4. The only WebKit developer that I was able to speak to (Xabier Rodríguez Calvar) refused to participate in the discussion, with the following arguments. First, he said that this has already been discussed at GUADEC and there is no point to rediscuss things where a conclusion has already been reached. Second, he insists that this not-a-bug is a logical consequence of complying with both W3C standatds and the requirement for GNOME desktop integration ("We want to be coherent with the rest of GNOME apps, and the volume model they are using"). Suggests complaining to W3C about their standards (but why should I do that? other brosers comply and don't have this problem, so the whole issue is in the desktop integration) or changing the volume model locally to the non-flat one (and I don't think it is a 100% fix, as the application-specific volume slider in gnome-volume-control would still disobey). Basically, the remaining question here is "where do I escalate this bug within GNOME teams?", as both PulseAudio and WebKit developers (more exactly, ONE developer) argue that there is nothing to fix on their side. I have already tried GNOME security team, got this response: the GNOME Security Team, such as it is, is not really capable of "forcing" a fix in some particular way where there doesn't exist a consensus already. Also tried assigning a CVE ID (http://www.openwall.com/lists/oss-security/2013/10/22/6), no reply yet.
Escalated to W3C, no response yet: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23642
It's not reasonable for web pages to have full control over the system volume, as your malicious example in the WebKit bug clearly shows. You can also escalate this to the GNOME release team. They obviously have no control over our dependencies, but they certainly can refuse to ship the browser so long as it exhibits this behavior. More likely, just having more people looking at the issue will break the impasse.
For your reference, this is now CVE-2013-7324. See http://www.openwall.com/lists/oss-security/2014/02/10/13 for the e-mail that confirms the assignment. However I think I did something wrong, as the Mitre page still lists this ID as reserved: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7324
*** Bug 737676 has been marked as a duplicate of this bug. ***
*** Bug 728425 has been marked as a duplicate of this bug. ***
(In reply to comment #0, bug #680779) > 2) pulseaudio folks recommend not exposing volume sliders in pulseaudio > applications at all (see e.g. http://pulseaudio.org/ticket/949#comment:1, and > IMHO this should apply to applications that use pulseaudio indirectly through > gstreamer) Hm....
The now-upstream recommendations are: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=3535fd7a076228fdeae3755cf8ac6fdcfa28741d (yes, this commit originally comes from me, but it has been reviewed by Peter Meerwald and the wording has been improved by Tanu Kaskinen).
Does anyone know a possible workarround for this? this kills my ears :/.
Been hitting this with youtube. I don't understand the "webkitgtk is spec compliant" and "desktop integration" bit, though. Sure it is complying with the spec, but the spec also allows the sane behaviour [1] which other browsers are implementing. As for desktop integration, letting a website push up the volume is annoying. My video player does not behave like this. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26828#c2 I have: epiphany-3.12.1-2.fc20.x86_64 webkitgtk3-2.4.6-1.fc20.x86_64
I just created https://bugs.webkit.org/show_bug.cgi?id=140287 to tackle this issue as there was a regression in my initial patch. As I commented there, it would be best to wait until the Browsers API is done in Pulseaudio and adapted in GStreamer, but for now we should fix the regression.
(In reply to comment #19) > I just created https://bugs.webkit.org/show_bug.cgi?id=140287 to tackle this > issue as there was a regression in my initial patch. As I commented there, it > would be best to wait until the Browsers API is done in Pulseaudio and adapted > in GStreamer, but for now we should fix the regression. It seems I couldn't find any regression to the behavior I had implemented to I am close the WK bug. I create https://bugs.webkit.org/show_bug.cgi?id=140358 though, to follow from WK any events in the Pulseaudio Browser's API. (In reply to comment #9) > 4. The only WebKit developer that I was able to speak to (Xabier Rodríguez > Calvar) refused to participate in the discussion, with the following arguments. Btw, this is simply not true. I talked to you there for about half an hour after my talk. In fact, all things you explain here were explained during that discussion we had. So I did discussed the issue with you for some time. I keep private my opinion about other impolite things that happened during that conference.
I think there is nothing to change in Epiphany, right? And several bugs have been created in WebKit Bugzilla, so closing this.
*** Bug 792837 has been marked as a duplicate of this bug. ***