The specific issue I am exploring is that of unpleasantly loud audio (usually from advertising media) on some web pages (usually written by a developer acting badly) and corollary, what counter-measures I should reasonably expect my browser to deliver natively. I use Nightly specifically because it does grant access to about:config settings but I am only a novice user of those settings. I am not strongly opposed to resorting to an add-on but I wish to first exhaust options for native support from Firefox Nightly.

• Q1 (generic) Where will I find discussion of or documentation (specifications, user manual, usage notes, self-documenting source code, etc.) for the various Firefox settings accessible via about:config ?
• Q2 (specific) What is the intended use scenario for the media.volume_scale setting?
• Q3 (specific) What is the intended use scenario for the media.default_volume setting?

I will refer to ~.volume wheｎ I am speaking of the value (programatically constrained to [0,1]) of the volume property of some HTML media element of interest.

As a well-behaved test case, I have used this w3c school "Tryit Edit" demo page (for A/V volume property) to better understand how a web page developer can use HTMLMediaElement.volume to manipulate volume without requiring user consent. (See image that might succesfully attach to the 2nd reply.)

What I have learned is:

1. the value assigned to ~.volume is on a linear scale from 0.0 (the same as mute) to 1.0 (full* volume); where full* volume is indeed the maximum volume as set by the user ahead of the browser loading the web page with a media element (please let's not go off on a tangent about what sounds linear to the ear but is actually logarithmic in terms of air pressure arriving at the ear) The important point to note here is that a "well-behaved" web page browsed via Firefox Nightly does indeed respect the user-prescribed maximum permited volume.
2. attempting to set ~.volume ouside [0,1] fails silently and the previous setting is preserved
3. setting media.volume_scale to a decimal fraction in [0,1) does not cause the effective volume to be louder than when media.volume_scale is set to the default value of 1.0. Indeed no effect is perceived! Yes, the test page is reloaded (rerun) each time a setting is changed in about:config
4. setting media.volume_scale to a decimal fraction in [1,1000] does not affect playback volume either!
5. setting media.default_volume to a decimal fraction in [0,1) does indeed cause audio playback to be at some other volume than the maximum volume as set by the user in advance of whichever web page loading; however this is able to be unilaterally overridden using script within the web page.
6. setting media.default_volume to 0 does indeed cause audio playback to be muted

• Q4 (specific) What is the intended use scenario for the media.hardwaremediakeys.enabled setting?

I have tried setting this as both true and false and in both cases the hardware media keys (on a bluetooth connected keyboard) are enabled for the test case web page referred to above. Those hardware media keys can start/pause playback, increase volume and decrease volume. They cannot mute, seek forward or seek backward. So this particular setting does not seem to have any effect that I can observe.

• Q5 (generic) Is it reasonable to expect that a browser be able to determine either the RMS or Peak loudness of the src for a media element and mute (i.e. set ~.volume=0) if that loudness is above some user specified level? For example:
  1. Might there be metadata within the file header that describes loudness just as there is metadata that describes duration?
  2. Might parsing just the first 3-5 seconds of the file be sufficiently manageable to estimate loudness without grossly impacting page load-time or grossly taxing the CPU?
  3. Might the default action be to set ~.volume=0 until such time as the browser has parsed the entire src to determine actual RMS loudness .. and only then restore ~.volume to user-prescribed maximum permitted volume iff RMS loudness is below a user prescribed threshold? (the bigger the file the longer that media is muted before it can be potentially unmuted!)

Once gain image attachments fail for the original post and for the 1st reply but mysteriously succeed for the 2nd reply. Very weird behaviour!

There does not seem to be any convenient way to share a code block for the test case HTML in this edit window's markup language: < pre < code ; ``` ; 4 spaces at start of every line ; etc. .. all the common inline markup methods all fail. You can read the code in the image attached and copy/paste many of the lines from below.

- - - - - - test case HTML - - - - - -

< !DOCTYPE html> 
< html> 
< body> 

<button onclick="getVolume()" type="button">What is the volume?</button>< br>
Set volume to:< br>
<button onclick="setVolume(-1)"   type="button">-1</button>
<button onclick="setVolume(0)"    type="button">0.0</button>
<button onclick="setVolume(0.25)" type="button">0.25</button>
<button onclick="setVolume(0.5)"  type="button">0.5</button>
<button onclick="setVolume(0.75)" type="button">0.75</button>
<button onclick="setVolume(1)"    type="button">1.0</button>
<button onclick="setVolume(2.5)"  type="button">2.5</button>< br>

< video id="myVideo" width="320" height="176" controls loop>
  < source src="mov_bbb.mp4" type="video/mp4">
  < source src="mov_bbb.ogg" type="video/ogg">
  Your browser does not support HTML5 video.
< /video>

< script>
var vid = document.getElementById("myVideo");
function getVolume() { alert(vid.volume); }
function setVolume(x) { vid.volume = x; } // no [0,1] constraint
< /script> 

< p>Video courtesy of 
< a href="https://www.bigbuckbunny.org/" target="_blank">Big Buck Bunny
< /a>.< /p>

< /body> 
< /html>

- - - - - - - - - - - - - - - - - - - - - - - -

Hi

Many of the prefs in Firefox for Android are set at the GeckoView level - the engine underneath Firefox for Android.

The prefs in about:config do not have a directory as they can be altered or removed with little notice while Firefox for Android is under construction.

WARNING from the moderator team: Changing Firefox pref from the about:config page can sometimes break Firefox or cause strange behavior. You should only do this if you know what you're doing.

Please read Firefox Advanced Customization and Configuration Options to learn more.

Looking at the issue you raise, what happens when you turn the device volume down?

Thank you, I have not yet begun to look into GeckoView. So it would be GeckoView that is responsible for faithfully implementing an API that is consistent with the HTML5 specification, correct? Firefox developers then use that API to do wonderful things for us users, correct? I find it helpful to understand such demarcation of function or responsibility.

Arrggg .. it is so frustating not knowing if an image upload for a reply will succeed or not!

{edit: When an image upload is successful it takes just a few seconds. When more than a few minutes pass for a 300kB image file then that cannot be brushed off as merely some upload bandwith problem .. and there is no way to cancel the upload attempt without also cancelling the reply editing! }

Looking at the issue you raise, what happens when you turn the device volume down?

Mmm ... if your question is asking what happens to the value of ~.volume when I change the volume using the rocker on my Android device then the answer is that the media element volume property value does not change when I change the Android device's Media volume using either the volume rocker or the equivalent hardwaremediakeys for volume control on my bluetooth connected keyboard.

Otherwise, I thought that I had adequately described what happens when the maximum permitted volume is set midrange (refer to the first numbered paragraph following "What I have learned is:" )

I will expand on that here ...

The volume rocker on my Android device will adjust volume setting for any of 4 sources: Ringtone, Media, Notifications and System. I have it locked to Media volume control (see image). Each volume range requires 15 presses of one side of the rocker to completely step through the full range of volume settings. Sometimes (usually after VLC has been used at least once) attempting to increase volume for step 9 to step 10 causes a warning about extended listenning at high volumes to appear.

If I use the rocker to set the Media volume to a midrange (e.g. 9/15) setting then upon loading the "well behaved" test case the initial ~.volume is always whatever media.default_volume has been set to (i.e. 1.0 if reset). That initial ~.volume value can easily be queried using the "What is the volume?" button on that test page. As best I can tell, the effective playback volume is always relative to the maximum permitted volume that I set using the rocker switch (9/15 in the example just given).

• So, a very low setting for media.default_volume will indeed initialise ~.volume but ...
• ... that value is then very easily changed by a script run by whatever page is loaded (as demonstrated by clicking on any of the "Set volume to:" buttons at that test page! .. or adjusting the volume slider which is only hidden from view due to the smallish 360x176 size that is currently rendered! see attached image)

Clicking any of the "Set volume to:" buttons on the test page to select 0.0, 0.25, 0.5, 0.75, 1.0 causes the effective playback volume to vary linearly over the range from muted to maximum permitted volume (9/15 in the example given above). Attempting to set ~.volume to a value outside the range [0,1] is silently ignored.

This is the expected behaviour based on my reading of the HTML5 specification. Sadly, it is not the actual behaviour observed at "badly behaved" web pages .. and those web sites usually rely on advertising to fund them.

I suspect that audio track compression is used by bad actors to increase the volume of an audio track while scaling down the peaks that otherwise would be clipped. I am still researching this.

Responding to your question has caused me to realize that the default media controls rendered by Firefox at that test page does not include any volume control. The speaker icon is just a mute/unmute toggle. This is not consistent with the HTML 5 specification. It turns out that increasing the size of that video element by 1.5x (to 480x264) caused the controls to include a short volume control slider next to the speaker icon. (see attached image) Adjusting that rendered volume slider does change the ~.volume values. So, well behaved web pages rendered by Firefox do indeed adhere to the HTML 5 specification in this respect.

{edit: finally the image uploads!}

There is no rhyme or reason as to when an image uploads successfully so .. I am giving up trying!

As for the 5 questions I posed .. 4/5 of them would seem to pertain to GeckoView as the renderer rather than Firefox as the browser.

Q5 might still be answered here or might be refered to some github issues/requests tracker, I am not sure...

I have no objection to a moderator closing this thread but would first appreciate a pointer to a relavent support forum for GeckoView.

Hi

I recommend that you head to https://mozilla.github.io/geckoview/ to contact the GeckoView community over Matrix.

Thank you for that pointer. It did not take too much digging to find discussion of issues that overlap a little with what I am looking into. This partial list of about:config settings expands upon what some allowed values are and that informal documentation did lead me to the Firefox Autoplay Policy which is very much relevant to my investigation. (Ironically that link was found right here within SUMO!) So it just goes to show that you need to ask just the right question in just the right way and then be read/heard by just the right person to get a helpful response.

WRT my Q5, where is a suitable place for discussion of this matter of reasonable criteria that an end-user might want/need to impose on media src before playback (whether that be autoplay or unmuted playback) is allowed/disallowed in the browser?

Although my current interest is in first knowing how loud an audio track will be before deciding whether I want it to play or not but it is perfectly reasonable for another user (say, someone who suffers from epilepsy or certain types of cerebral palsy) to first know if there is any video that might include strobing in some specific range of the colour spectrum before deciding whether they want to allow the playback.

The whole attractivenes of using a browser (rather than a cacophony of Apps) to view information from the world wide web is that bad actors remain on notice that the end-user can and always will shape their experience using the internet such as by filtering content that does not satisfy an end-user's criteria. If a sincere organization wants my attention then they must behave in a way that I approve of before they will receive that attention.

• Gratuitously causing me or my sleeping room mate distress is not good behaviour. (Does no enrich my life!)

Historically, mozilla browsers (I think Netscape was the first mozilla browser, correct?) have afforded end-users tools to filter content and so keep the technology working for the user rather than the user working for the technology.

It concerns me that some day (with the likes of DRM, DMCA-like laws and now, EME) it may very well become unlawful to pre-scan internet content to check for bad behaviour before allowing or not allowing that content to display or playback .. even in my browser! That is the kind of anti-competitive behaviour that leads to an internet that favours established commercal interest over serving the general public or enabling new, disruptive (and potentally better for the public) commercial interests.

Thank you for that pointer. It did not take too much digging to find discussion of issues that overlap a little with what I am looking into. This partial list of about:config settings expands upon what some allowed values are and that informal documentation did lead me to the Firefox Autoplay Policy which is very much relevant to my investigation. (Ironically that link was found right here within SUMO!) So it just goes to show that you need to ask just the right question in just the right way and then be read/heard by just the right person to get a helpful response.

WRT my Q5, where is a suitable place for discussion of this matter of reasonable criteria that an end-user might want/need to impose on media src before playback (whether that be autoplay or unmuted playback) is allowed/disallowed in the browser?

Although my current interest is in first knowing how loud an audio track will be before deciding whether I want it to play or not but it is perfectly reasonable for another user (say, someone who suffers from epilepsy or certain types of cerebral palsy) to first know if there is any video that might include strobing in some specific range of the colour spectrum before deciding whether they want to allow the playback.

The whole attractivenes of using a browser (rather than a cacophony of Apps) to view information from the world wide web is that bad actors remain on notice that the end-user can and always will shape their experience using the internet such as by filtering content that does not satisfy an end-user's criteria. If a sincere organization wants my attention then they must behave in a way that I approve of before they will receive that attention.

• Gratuitously causing me or my sleeping room mate distress is not good behaviour. (Does no enrich my life!)

Historically, mozilla browsers (I think Netscape was the first mozilla browser, correct?) have afforded end-users tools to filter content and so keep the technology working for the user rather than the user working for the technology.

It concerns me that some day (with the likes of DRM, DMCA-like laws and now, EME) it may very well become unlawful to pre-scan internet content to check for bad behaviour before allowing or not allowing that content to display or playback .. even in my browser! That is the kind of anti-competitive behaviour that leads to an internet that favours established commercal interest over serving the general public or enabling new, disruptive (and potentally better for the public) commercial interests.

Firefox is not going to know how loud a video is before you start playing it, and it is not going to be possible to know about any light effects that may cause harm, although some content providers do warn users before a video starts playing.

You may want to look at content blockers available for Firefox for Android from the Add-ons option in the Firefox for Android menu.

Thank you.

Feel free to close this thread

Ok, will do.