This is opened to address problem according to W3C accessibility guildline. Checkpoint 3.3 and 3.4 - Allow user to turn on and off rendering of video and audio.
Those are priority 1 items.
How does "video" differ from image animations, and how do you distinguish them, ie should there be two prefs? Why would you want to block "sound", rather than just "background sound"?
lake, please check with browser group to see who/whether is doing this, then reassign it to proper engineer.
Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.
Audio, video, and other plugins should be controlled with the same prefs used to control images. They are going to be turned on and off for exactly the same reasons -- bandwidth, distraction, whatever -- so it makes sense to use the same controls. 4.X started doing this: for some values of X on some platforms, the Advanced prefs had not `Automatically load images', but `Automatically load images and other data types'. However, as far as I could tell no version ever got around to actually putting the `and other data types' part into effect. To help with accuracy in the prefs, you could change `Images' to `Multimedia', or `Images & Media'.
No way, not everything comes down to bandwidth, or if it does, people place differentthings ast different importances. Animations and moving video could theoretically cause problems for people who are epileptic or experience motion sickness. They could want images, just not moving ones unless they say otherwise on a case-by-case basis. Background sound annoys most people, but they still want their graphics, possibly moving ones. There are a whole raft of reasons to make them separate.
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs to Matthew Thomas (firstname.lastname@example.org). Matthew Thomas is now the QA owner for the User Interface: Design Feedback component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser should continue be QA assigned to email@example.com.)
If we need to have this as a separate feature, I need some more information on how mozilla handles video and audio separately form the background sound and simple animations. I thought that the real video and streaming audio were handled by plugins like Spinner and such. Wouldn't these handle the special volume and presentation rate individually while Mozilla handles general animation and background sound?
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
updating to new owner. sorry for the spam.
I believe we need something like this: SetBoolPref("capability.acceptmedia.mimetype", PR_TRUE /* or PR_FALSE */); Where the mimetype is the media type in question. With that pref capability, the front end UI people can decide to group more than one thing under "video" or "audio".
i'm pretty sure that prefs.js uses js values, so true or false, not PR_.. however I suspect that mimetype containing / would be bad for a pref name we could have it contain a list of mime types SetPref("capability.acceptmedia","image/png image/jpg"); SetPref("capability.rejetmedia","image/gif"); [i'm not sure that SetPref is the right name for string prefs)
That would be fine (SetCharPref) with me also. We would only need a capability.rejectmedia though, acceptmedia would be the default. This would also take care of the audio portion of bug 24418
Sorry, correction, I meant it would help with 19260
Aaron, the other day you indicated on IRC you was thinking on having back end support for formats while maybe just having a boolean in the UI. How would the UI handle it if you had partial disabling on the back end?
Matthew, you make too much sense. We'll have to come up with a solution for that, because we don't want to require users to know the different formats. Yet, we want to allow those detailed settings to be made by advanced users. Possible design (big disclaimer here, it's late and I'm sure there are better ideas, but this might help get the ball rolling). German, Ben or mpt can come up with something better, but this would support the structure we need. Video and animations: [ ] Mpeg [ ] Gif [ ] Mng [ ] Real [ ] Quicktime (Enable all) (Disable all) Audio: [ ] Mpeg [ ] Real [ ] Quicktime (Enable all) (Disable all) Clicking on the enable all or disabled all button could set the other checkboxes. For advanced users and other media types, we could offer something in the Prefs - Navigator - Helper Applications, where they add a mime type, and can enable or disable any media type they want there.
When I suggested separating formats it was purely because it made much more sense to me than the arbitrary distinction of "video" and "animations". However, I still don't see any benefit to exposing more than a simple on/off for all moving pictures to the user. Of course, if someone can provide a use case I might change my mind. I appreciate your concern for future extensibility and changing needs but I would rather see the format separation not implemented at all on the back or front end, and rather make the code and original prefs so they are easily changeable to add this in later. So for example you would have a simple on/off, but later you might add a pref for a list of reject formats if that proved to be necessary. If however we do go down this route, I would feel much more comfortable with UI something like: Video and animations: [ ] All Types [ ] No Types [ ] Certain Types (Edit Types) rather than putting a bunch of gobbledegook for newbies to parse.
Sounds okay by me. German, what do you think for a UI on this one?
Or even better: ----------------------------------------------- View images and animations [ ] Always [ ] Never [ ] Prompt There are no exceptions currently defined. ( Edit Exceptions ) ----------------------------------------------- This should apply for all bug #7380 prefs. Whether you allow distinguishing on format rather than just site/domain/url is independent. I can see a benefit of distinguishing formats if you know what the site is, however I doubt the existing site-by-site prefs architecture would allow AND/OR rules, and I haven't had a chance to look yet. Another issue is what to do if you're at the actual video's URL as opposed to the page itself. There needs to be a way for people to easily be able to view a specific video. What do people think the best way of doing this is? Maybe we could give a prompt regardless if videos are off for the URL and we're at the actual URL. Or maybe we could have a fourth option "Only at specific URL" (replace with decent name).
Actually we are working on per site prefs, for the general case. As far as prompting, we were actually thinking of replacing that with iconified warnings for conditional content near the lock icon at the bottom of the window. Users would also be given the option of auditory warning that such content was waiting. Upon clicking on one of the conditional content icons or pressing Accel+T, the user would have the chance to toggle that content for the particular URL. We're going to try to satisfy W3C's WAI guidelines (UAAG - User Agent Accessibility Guidelines). www.w3.org/wai/ua Anyway, this is all very new and rough. German and Ben were going to design UI for this, I'll be quiet now. I think we should all design this off-line, because this bug report will get oftly long and unreadable if we use it to solve all of our problems in this area.
*** Bug 88193 has been marked as a duplicate of this bug. ***
*** Bug 100819 has been marked as a duplicate of this bug. ***
*** Bug 59026 has been marked as a duplicate of this bug. ***
I like to play music while I look at porn so I can be sure that people walking past my room don't hear me. But several porn sites have a loud background sound of a woman screaming, so I'm forced to turn off my speakers while I surf porn. I need to be able to disable those sounds, but I'd like to be able to temporarily enable sound to watch a porn video once I have my headphones plugged in.
*** Bug 109643 has been marked as a duplicate of this bug. ***
a simple "enable/disable other media" in the view menu should suffice. since this would be a low frequency feature, i doubt we need to supply too many controls in prefs.
Aaron wrote: "We'll have to come up with a solution for that, because we don't want to require users to know the different formats. Yet, we want to allow those detailed settings to be made by advanced users." If the backend prefs supported wildcards in the MIME types, it could be fairly simple. The "Block video" pref would block loading of video/* content, "block sound" would block audio/* content, etc.
*** Bug 153870 has been marked as a duplicate of this bug. ***
*** Bug 159877 has been marked as a duplicate of this bug. ***
| +-----------------+-+ Multimedia ::::::::::::::::::::::::::::::::: | | | Languages | | | | | Connection | | [/] Ima_ges [/] _Normal frames | | | Start Pages | | [/] _Backgrounds [/] _In-line frames | | | Fonts | | [/] _Animations [/] Always allow frame | | | Colors & Effects| | [/] _Looping _resizing | | | Helper Programs | | [/] _Sounds [/] Always allow frame | <- Bing! | |:Multimedia::::::| | [/] _Videos scrollin_g | <- Bing! | | Scripts&Windows | | ( _Filters... ) There are no filters active. | | | Privacy | | | | | History & Cache | | [ ] Show _caret for keyboard selection | | | Web Forms | | Use Tab/Shift+Tab to navigate between: | | | System | | [/] for_m controls [/] lin_ks [ ] o_bjects | | | | | | | +-----------------+-+ :::::::::::::::::::::::::::::::::::::::::::: | Back end is easy: just either do nothing, or not, if the MIME type is audio/* or video/* respectively. There is no need to generalize this for all MIME types. I repeat, there is no need to generalize this for all MIME types. Don't make this uselessly complicated. --> Preferences
*** Bug 162505 has been marked as a duplicate of this bug. ***
*** Bug 186939 has been marked as a duplicate of this bug. ***
*** Bug 187941 has been marked as a duplicate of this bug. ***
*** Bug 214942 has been marked as a duplicate of this bug. ***
*** Bug 219387 has been marked as a duplicate of this bug. ***
*** Bug 221351 has been marked as a duplicate of this bug. ***
*** Bug 221672 has been marked as a duplicate of this bug. ***
Is there a plan to fix this sometimes ? Web pages that automatically play a sound when loaded really get on my nerves (especially when I'm already listening to an mp3...). Is it that difficult to add a configuration option (like there already is to disable automatic pop-ups) ? Example page: http://www.metrobus.fr/metrobus_news_3.htm (enjoy!) (forwarded from http://bugzilla.gnome.org/show_bug.cgi?id=127599)
*** Bug 179424 has been marked as a duplicate of this bug. ***
*** Bug 227070 has been marked as a duplicate of this bug. ***
An audio blocking feature similar to popup blocking would be handy; I often open and then have to go back to my main task. When something starts playing in the background, its disconcerting and also I have no idea which of the many tabs I have up is causing the sound. The poor blighters who work in cubes could get embarrased when odd (and maybe obscene) noises are blasted out. When audio is blocked an icon could show up in the status bar like the one for popups. Flash blocking would be handy too.
*** Bug 237570 has been marked as a duplicate of this bug. ***
*** Bug 238918 has been marked as a duplicate of this bug. ***
*** Bug 240855 has been marked as a duplicate of this bug. ***
4 years, no fix. Just mark it as WONTFIX so we can get on with our lives. I'd do it myself on Win32 if the build process didn't require MS Visual C++.
*** Bug 246610 has been marked as a duplicate of this bug. ***
It looks like the solution to this was developed two years ago. If there are some good docs on the structure of the mozilla source code, point me at them and I'll dig into it...
*** Bug 257444 has been marked as a duplicate of this bug. ***
*** Bug 281218 has been marked as a duplicate of this bug. ***
*** Bug 303218 has been marked as a duplicate of this bug. ***
I've filed Bug #318988 to request the same feature for Firefox.
*** Bug 318988 has been marked as a duplicate of this bug. ***
Can someone please change the Product field of this bug to Firefox and component to Core as alluded to in Bug 318988?
I'm not sure this is the same as Bug 318988 since this is (or was) for the suite. Is this in the core?
See also bug 333208, which asks for a global volume limit.
This really is a Core bug and I'm moving it there per bug 318988 comments 3 and 8.
How about just setting all content to have 'autostart="false"' and a way to start hidden embeds? That may be a sufficient workaround....
*** Bug 357533 has been marked as a duplicate of this bug. ***
(In reply to comment #42) > An audio blocking feature similar to popup blocking would be handy; I often > open (In reply to comment #42) >How about just setting all content to have 'autostart="false"' > and a way to start hidden embeds? Actually this has been "fixed" in an extension named "Stop Autoplay" (https://addons.mozilla.org/firefox/1765/). > Flash blocking would be handy too. This also exists as an extension named "Flashblock" (https://addons.mozilla.org/firefox/433/). So this bug is actually fixed, but you have to find and install an extension (or two). Besides these extensions doesn't allways work perfectly (at least flashblock sometimes need a refresh to work on my computer). It would be very nice to have some of this functionality directly in firefox.
A user requirement: Problem: Sound is desired for certain websites, like gmail (gtalk alerts), youtube, etc. but not for the majority of sites. When a site starts playing undesired sounds, the knee-jerk of the user is to turn off their speakers, thus disabling sound for the entire system. Possible solution: Have a whitelist of sites that sound is desired from. If a non-approved site tries to play sounds, prompt the user if they want to add the site to the approved list.
Dup of bug 94035? (Or at least, solving that one would solve this one too.)
No, not really. That's about blocking by media type. This is about disabling sound as a whole or video as a whole, regardless of media type. Some media types, such as Flash, are multi-modal and contain both video and audio. It's perfectly reasonable to want to allow Flash but disable all sound (for example, if you're already listening to music).
I think that sounds should be authorise by tab: user should be able to stop sound for a tab and listen at an another. Only the select tab have to be enabled, but the user might enable others tabs, if he wishes so.
The ability to EASILY switch off sound for a tab would solve the requirement mentioned in comment #66. In this case instead of switching off sound for the system, the user could switch off sound for the annoying tab. In response to some comments: it IS sometimes required to listen to sounds on a tab not being viewed, i.e. gtalk alerts in gmail.
The ability to change sound level quickly is at least as important.
There was talk, back in 2007, of adding a mute button so that you could mute tabs individually or mute everything, which I found @ https://wiki.mozilla.org/Firefox/Feature_Brainstorming:User_Interface#Mute_Button. I and a million other Firefox users would go for something like that as part of the browser's core functionality. :)
Sound when open a page is a problem. I think it must have a fonction to set if the user want to have sound when he opens a page. Sound on some tabs when Firefox is restarted after a crash is a very big problem if firefox reopens a lot of tabs ... but firefox has a option to not reload automatically the pages in the Tabs: after a restart, the user must click on the tab and the page reopens ... this option is a good way to avoid that firefox reloads several pages with sound in the same time.
There are newer bugs specifically for HTML audio/video as well as for NPAPI plugins. Closing this one out since it's not tracking anything useful now.
Thanks much for listing those newer bugs so that all 83 CCs and reporter can individually hunt them down to follow and/or comment. Personally I don't see how "newer" adds any value, while newer does provide negative value in masking the age of the problem here reported 13 years ago. No one should have to disable all system sound in order to counteract this glaring _user_agent_ shortcoming. DejaVu DRL.
Are there guidelines to prevent the replacement of "older" bugs by "newer" Mostly what happens is that the original context is "lost" and the bug is subsequently then resubmitted... wasting every one's time This feature is important for xul app developers - not the Firefox interface
Is there any progress in making possible to disable all sound? I see the last comment is from year 2014, and year 2015 is near its end already. This feature is absolutely must have given that really many websites out there in a wild forcibly play various sounds and give no option to disable them (and even if they do, you'll hear them before you go and disable them, because they tend to be enabled by default)
Also: Chrome and Safari already allow this, and even muting single tabs
maybe something for next year's plan?
baku, kentuckyfriedtakahe, how closer are we to doing this now that we have per tab audio muting? Anything we'd need to do for video playback here?
2 years ago
FYI, previously functional hidden option `dom.audiochannel.mutedByDefault` doesn't work anymore (at least on FF 55.0.2), the sound can still be played even if this option is set to true. Can this be fixed?