Open
Bug 497164
Opened 15 years ago
Updated 2 years ago
Volume settings (e.g. mute) are not persistent - always 100% after load
Categories
(Toolkit :: Video/Audio Controls, defect)
Toolkit
Video/Audio Controls
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox33 | --- | affected |
People
(Reporter: whimboo, Unassigned)
References
(Blocks 1 open bug, )
Details
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090608 Shiretoko/3.5pre ID:20090608031104
The volume settings are always set to 100% when a video has been loaded. Any previously set volume is not remembered. That also applies to the unmute state. The latter one can be serious in areas where you don't wanna play audio. We should remain the volume state.
Steps:
1. Load video: http://tinyvid.tv/show/36mvdjoflfskb
2. Adjust volume, e.g. set it to mute
3. Go Back
4. Go Forward
After step 4 the volume is again at 100%.
Flags: wanted1.9.1.x?
Comment 1•15 years ago
|
||
Over the issue with perhaps persistent muting throughout a session, I questioned and proposed the problem and a possible solution.
Since controls on a video auto-hide, persistent muting might confuse end users who accidentally enable mute and are surprised to find out that all remaining videos they view in session are inaudible.
Possible solution would be small upper right icon of a muted speaker (i.e., http://i40.tinypic.com/307np53.jpg [excuse the laziness to re-size the speaker layer])
Any comments are welcome
Strictly speaking, this is a feature request for some control settings to be persistent.
Comment 3•15 years ago
|
||
Volume settings are per video, not browser wide. So if you mute a video you are muting only that video. I don't think we want to persist settings on individual elements of pages that may change. We should probably have browser wide volume settings in the UI somewhere.
Reporter | ||
Comment 4•15 years ago
|
||
Either way would be fine. Just to give an example why I think this is useful: Yesterday during the developers meeting I tried to run a couple of tests for bug 494305. So each time I opened a video which was autoplay=true I was confronted with a high volume which was hurting my ears because the system volume was at 100% too due to a lower volume of the call.
It would be really nice when we could be smart and handle it browser wide.
Comment 5•15 years ago
|
||
I'd lean towards just having a single browser setting for "default volume level", instead of persisting volume changes. I'm mainly concerned that having volume changes persist on a per-video/page/site basis would end up becoming annoying or confusing, because you'd start seeing videos at seemingly random settings. Or consider the example from comment 4 -- the system volume is high for a special external reason, but when it's back at normal levels any persisted settings will then be too low.
Shaver's mentioned wanting a way to have the volume start at 50%, so that the system volume can be a bit high, and then the volume can be adjusted to louder/quieter than normal. A single pref would help with that case too.
Comment 6•15 years ago
|
||
The spec used to have the volume set to 50% but was changed quite a while back to 100%. I actually prefer 50% as this means the user can make the volume louder using the volume control. Set to 100% by default the only initial option is to make it quieter.
Updated•15 years ago
|
Flags: wanted1.9.1.x?
I think Ogg video player should save volume setting same as YouTube does. I find the problem is still there in Firefox 3.6 beta 5
When choosing a volume setting on a video and later open another OGG video, the volume goes back to maximum volume.
Steps to reproduce:
1. go to http://tinyvid.tv/
2. Open a video
3. Lower volume setting
4. Open a new video
What happens: video has maximum volume again
What should happen: The volume setting should stay the same as it was set the first time when the video player was used.
Version used:
Firefox 3.6 Beta 5
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5
Comment 12•10 years ago
|
||
This started happening to me within last week with nightly. Any video will revert to max volume. After adjusting the volume if you skip to a point in the video it will reset to max volume again.
I am on archlinux and I build nightly using https://github.com/shosca/-pkgbuild-mozilla-git/blob/master/firefox-nightly/PKGBUILD
Comment 13•10 years ago
|
||
This is known (bug 1049478) and will be fixed tomorrow.
Updated•10 years ago
|
status-firefox33:
--- → affected
Updated•9 years ago
|
Component: Audio/Video → Audio/Video: Playback
Comment 15•9 years ago
|
||
Moving over to Toolkit :: Audio/Video Controls as this is pretty much a front-end feature.
Component: Audio/Video: Playback → Video/Audio Controls
Product: Core → Toolkit
Comment 16•7 years ago
|
||
I am using Firefox 53.0.3 (64-bit) on Windows 7 (64-bit) with the following code in a web page I created:
<audio autoplay="" controls="controls" preload="none">
<source src="http://radiodave.org:8000/mp3-stream" type="audio/mpeg">
Sorry your browser does not support the HTML5 audio element, suggest you update.
</audio>
When the page displays the audio element play bar displays including the volume control briefly. Then the playback starts at full volume and the volume control disappears. The rest of the play bar remains. If I right click on the play bar then select "Inspect Element", then close the inspection window, the volume control is now visible and works properly. Anytime the page is re-displayed it's back to full volume with no volume control.
Comment 17•7 years ago
|
||
Follow up to my previous comment:
1. The same page using the above code plays with the volume control on both Internet Explorer 11 and Opera browsers.
2. The same page on my Samsung Galaxy S5 phone with Android 6.0.1 using Firefox 53.0.2 behaves as follows:
Autoplay does not start. The play bar displays with the "play button". Selecting play starts the audio at full volume. There is no volume control.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•