We've talked about this feature our whole lives and 3 months before birth in the gestation period, but we never knew how to do it. However, developer Yuan Xulei has created add-on "Muter" (https://addons.mozilla.org/en-US/firefox/addon/muter/?src=cb-dl-updated) for Linux. I think this is enough reason to look into the possibility of mute-per-tab again. I'm going to try and reach out to Yuan to work with us, or perhaps a dev can examine this code and see if what he did can be applied across platforms and added to Firefox. Either way, let's give this the chance to be real - it's one of our most consistently requested features. If any developer thinks they have an idea on how to implement, please comment or email me and we will make this thing real.
So uh, FWIW, that addon just lets you mute the entire browser. From poking around through the source, it appears to do all sorts of horrible hooking into system libraries to do it. But hey, how about I just CC our Chinese colleagues who wrote it!
(In reply to Ted Mielczarek [:ted, :luser] from comment #1) > So uh, FWIW, that addon just lets you mute the entire browser. Damn - right you are. It's a good start, though. We could change the scope of this bug to be per browser session rather than per tab. However, Beltzner notes that if we can find Flash APIs that we can call to, we could send a signal to every flash embed in a DOM tree saying "mute" (see Bug 593897)
Just for reference, an equivalent Chrome extension: http://code.google.com/p/chrome-toolbox/source/browse/trunk/release-1.0.29/plugin/browser_mute_script_object.cc
I'm the developer of Muter. As Bug 593897(https://bugzilla.mozilla.org/show_bug.cgi?id=593897) mentions, threre is no general method to change plugin volume by tab without NAPI modification. So currently controling a specified tab's volume is difficult. However it is doable to control by tab without plugin. I agree with Jennifer Morrow that it is feasible to create per browser volume controller rather than per tab. Win7 and lots of latest linux distributions provide per-process volume controlling API. Vista and WinXP don't provide these APIs, but we could 'hook' into system libraries to do it. The remaining problems is to support Mac OS and other linux systems without per-process volume controlling API. Maybe we can 'hook' them as well.
As a note, some sites do FORCE you to not be able to turn off sounds (Enjin is one for their chat system)
So I need per-tab, not browser.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #1) > So uh, FWIW, that addon just lets you mute the entire browser. From poking > around through the source, it appears to do all sorts of horrible hooking > into system libraries to do it. > > But hey, how about I just CC our Chinese colleagues who wrote it! Hey Ted, is it likely that we can detect some sources of sound easily, like HTML5 elements? I'm assuming Flash & the rest will be harder, but starting with indicating the tab creating sound (and allowing the muting of that tab) just for the sound we *can* detect could be a good start on this problem.
(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #8) > Hey Ted, is it likely that we can detect some sources of sound easily, like > HTML5 elements? I'm assuming Flash & the rest will be harder, but starting > with indicating the tab creating sound (and allowing the muting of that tab) > just for the sound we *can* detect could be a good start on this problem. Yes, that's almost certainly doable. roc (or someone else who actually works in media) could confirm.
I think we should consider leveraging nsIAudioChannelAgent. nsHTMLMediaElement already knows to create an AudioChannelAgent when the right pref is set, and AudioChannelService manages the set of AudioChannelAgents, and it works with e10s already. An AudioChannelAgent can mute the audio. Web Audio doesn't have an AudioChannelAgent but it will need one (as will every other browser audio source). If we do it that way, we'll need to create a way to associate tabs with AudioChannelAgents. Perhaps we should use the tab's MessageManager so things work with e10s. Then we'd need to make AudioChannelService run on desktop and build hooks into it so chrome script can monitor/change channel states.
Since we're planning for Q1... could we please make this a higher priority? Seems like support is falling in place (as stated by baku in http://143th.net/post/79292963535/audio-volume-and-mute-per-window-object ) and people are desperate for this feature for obvious reasons in this time and age of lots of open tabs
I think fixing this for the non-plugin case would help a lot of people and be a useful feature.
We have support for doing this for HTML audio, but not for plugin-based audio. I suspect plugin-based audio is still most common on the web (though with Youtube gradually switching over to HTML5 video, this may change). I think introducing this feature without support for plugin-based audio is likely to be very confusing.
FWIW the Gecko bits required to support this for non-plugin audio have landed a long time ago in bug 923247. In bug 1167690 we are adding an NPAPI API which would let the plugin mute one of its instances, but not change the volume.
WE need per tab volume sites like bandcamp / soundcloud that sadly don't give any in page volume controls. Are any experiments planned that would support this in multi-threaded tab mode?