Konqueror (both in KHTML mode and in WebKit mode, but let's restrict this bug to KHTML) has a bug related to its handling of javascript-settable volumes for HTML5 audio elements. The _bug_ is: A malicious piece of javascript on the web page can cause an audio file to play at some volume, without the user being able to move the corresponding slider in pavucontrol or kmix or whatever other pulseaudio-based mixer application. I.e. just a "stuck slider" annoyance-class bug, but still a bug that, when fixed, will eliminate the vulnerability below. The _vulnerability_ below is a logical consequence of the bug above. It applies if PulseAudio is in the flat-volume mode (which is true by default, except on Ubuntu) and something too-sensitive (e.g. headphones) is connected to the sound card output. The _vulnerability_ is: A malicious piece of javascript on the web page can cause an audio file to play at unexpectedly high volume (up to 100% of the volume that the hardware is capable of, which is way too much e.g. for some headphones), and not let the user move the volume slider corresponding to the web browser, move the "master" volume slider, or mute it. This malicious piece of javascript just sets the volume to 99% or 100% repeatedly using a timer. The example script does not illustrate the "can't mute" part of the bug, but every bad guy with some javascript knowledge can add the "repeated unmuting" part himself. Reproducible: Always Steps to Reproduce: 0. Ensure that flat volumes are enabled in /etc/pulse/daemon.conf 1. Start Konqueror 2. Go to http://jsfiddle.net/bteam/FbkGD/ (without anything sensitive connected, otherwise I am not responsible for any damage). 3. Notice the volume in kmix. Try to reduce it. Actual Results: The volume is 100%, and attempts to reduce it fail. In the worst case, fried speakers and/or very angry neighbours. Expected Results: The volume should stay what it was before, and should be changeable using kmix. There should be no slider in kmix that disobeys the user! The same bug in GNOME's browser is at https://bugzilla.gnome.org/show_bug.cgi?id=675217 The root cause of the bug is that KHTML directly connects the javascript-settable volume to pulseaudio stream volume, thus effectively disabling the slider if javascript does something bad. Instead, as all Windows-based browsers do, KHTML should attenuate the audio samples _before_ sending them to the system, so that the javascript-settable volume applies as an extra factor on top of the volume set by the user in kmix, not instead of it. There are web apps in the wild that assume that setting their volume to 100% is safe, because they expect the relative-to-system-mixer volume model. E.g. http://www.fungamescool.com/FunWithDynamite/fun-with-dynamite.html It is a documented feature of PulseAudio that, in flat-volume mode, it treats stream volumes relatively to the hardware maximum volume. On LinuxCon Europe 2013, during the audio miniconf, this has been discussed in the GNOME context and decided that it is not a bug in PulseAudio, i.e. that it is a responsibility of a browser to sandbox javascript-initiated volume changes.
Note that this was previously reported as a security issue however I requested it be filed as a normal bug since I believe just to be a normal bug.
For the record this is true for the major web browsers as well. The same thing happens if you try it with the latest versions of Firefox and Chromium as well.
Thanks for the alert. I will retest these browsers tomorrow, and, if the test yields 100% hardware volume, pass the information to their vendors, too. It would help if you specify the exact versions and any non-default settings (e.g. such as the use of GStreamer backend in FireFox).
Dawit, As per your report in comment #2, I have installed the following browser versions: Firefox 25.0.1 Chromium 33.0.1707.0 (234359) (i.e. from the dev channel) and visited the demo page there. I could not reproduce the bug. Based on that, I guess that you have misunderstood the original description of the bug. Let me clarify. The fact that the volume control inside the browser window (if it shows such control for an audio element) is pegged to 99-100% is expected in all browsers and is not a bug. The fact that the browser-specific volume control in kmix is pegged (which is true for KHTML, but not for Firefox and Chromium) is the subject of this bug. If you are still confused, please say so, and I will find alternative means (such as screenshots) to explain.
(In reply to comment #4) > Dawit, > > As per your report in comment #2, I have installed the following browser > versions: > > Firefox 25.0.1 > Chromium 33.0.1707.0 (234359) (i.e. from the dev channel) > > and visited the demo page there. I could not reproduce the bug. Based on > that, I guess that you have misunderstood the original description of the > bug. > > Let me clarify. > > The fact that the volume control inside the browser window (if it shows such > control for an audio element) is pegged to 99-100% is expected in all > browsers and is not a bug. > > The fact that the browser-specific volume control in kmix is pegged (which > is true for KHTML, but not for Firefox and Chromium) is the subject of this > bug. > > If you are still confused, please say so, and I will find alternative means > (such as screenshots) to explain. No I completely understood the description you provided the first time. I just made the mistake of running Konqueror while testing the other browsers. Anyways, I stand corrected. It only happens in Konqueror with either browser engine. For webkit engine I can tell you that it is an upstream issue and needs to be reported there.
For Qt-Webkit engine this has been already reported upstream. See https://bugreports.qt-project.org/browse/QTBUG-34896
Dear user, KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6. Please migrate to use a QWebEngine based HTML component. We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes. For security issues, please see: https://kde.org/info/security/ Sorry that we did not fix this issue during the life-time of KHTML. Greetings Christoph Cullmann