Open Bug 24418 Opened 25 years ago Updated 2 years ago

[meta] Allow user to turn on and off rendering of video/audio (disable sound)

Categories

(Core :: Audio/Video: Playback, enhancement)

Product:
Core
Component:
Audio/Video: Playback
Type:
enhancement

Tracking

()

People

(Reporter: xiaotong, Unassigned)

References

(Depends on 4 open bugs, Blocks 2 open bugs)

Details

(4 keywords) 

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.
Blocks: uaag
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.
Assignee: shuang → lake
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
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'.
OS: Windows NT → All
Hardware: PC → All
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 (mpt@mailandnews.com).

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 elig@netscape.com.)
QA Contact: elig → mpt
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?
Keywords: access
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...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: lake → mpt
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. ***
These four bugs are related:

bug 11875 stopping animations with Esc should also stop applet animations
bug 19118 Plug-In Manager (ui for choosing mimetype-plugin associations)
bug 24418 Allow user to turn on and off rendering of video/audio 
bug 94035 Allow blocking of any media type by site
*** 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.
Keywords: privacy
Whiteboard: [Aufbau-P3]
Whiteboard: [Aufbau-P3]
*** 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.
Blocks: 147866
*** 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
Assignee: mpt → ben
Component: User Interface Design → Preferences
QA Contact: zach → sairuh
*** 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...
Flags: blocking1.8a2?
Flags: blocking1.7.1?
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0?
Flags: blocking1.8a2?
Flags: blocking1.8a2-
Flags: blocking1.7.1?
Flags: blocking1.7.1-
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
*** Bug 257444 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Summary: Allow user to turn on and off rendering of video/audio → Allow user to turn on and off rendering of video/audio (disable sound)
*** 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. ***
Assignee: bugs → prefs
QA Contact: bugzilla
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.
Component: Preferences → Plug-ins
Product: Mozilla Application Suite → Core
Assignee: prefs → nobody
QA Contact: plugins
Blocks: 333208, 339019
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. :)
Severity: normal → enhancement
Priority: P3 → --
Blocks: 728046
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
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.
No longer blocks: 333208, 728046
Depends on: 665598, 333208, 728046, 449336
No longer blocks: 339019
Status: RESOLVED → REOPENED
Component: Plug-ins → Tracking
Depends on: 334987
Keywords: meta, ux-control
QA Contact: chofmann
Resolution: INCOMPLETE → ---
Summary: Allow user to turn on and off rendering of video/audio (disable sound) → [meta] Allow user to turn on and off rendering of video/audio (disable sound)
Status: REOPENED → NEW
Depends on: 593897, 486262, 479622
Depends on: 661822
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
Depends on: 759964
Depends on: 459559
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)
Flags: needinfo?(chofmann)
Also: Chrome and Safari already allow this, and even muting single tabs
maybe something for next year's plan?
Flags: needinfo?(chofmann)
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?
Depends on: 1188978
Component: Tracking → Audio/Video
Component: Audio/Video → Audio/Video: Playback
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?
We're working on something in the area (autoplay blocking), and more info will come soon.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.