Request: Prefix <title> with ▶ when <video> or <audio> is playing in that tab

RESOLVED DUPLICATE of bug 486262

Status

()

Core
Audio/Video
--
enhancement
RESOLVED DUPLICATE of bug 486262
7 years ago
3 years ago

People

(Reporter: Mathias Bynens, Unassigned)

Tracking

({uiwanted})

Trunk
x86
Mac OS X
uiwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.642.0 Safari/534.16
Build Identifier: 4.0b10pre

It would be great if the <title> of a document (as displayed in its tab) would automatically get a prefix like ▶ if video or audio is currently playing in it.

This would make it easier to track down which tab is making noise.

http://soundcloud.com/ and http://hypem.com/ are popular sites that already do this through some scripting, but it would be very useful to have this kind of functionality baked into the browser.

Reproducible: Always

Actual Results:  
There’s no indication of media playing in a tab.


This would definitely be a useful addition.

Updated

7 years ago
Component: Tabbed Browser → Video/Audio
Product: Firefox → Core
QA Contact: tabbed.browser → video.audio
Version: unspecified → Trunk
If the audio is playing through flash or some other plug-in, then we just don't have the information that it's playing audio.  It's talking directly to the OS audio services, completely bypassing our code.  So we can't indicate that it's playing audio... we don't know that it is.
Or is this really about the case of <video> and <audio> elements?  I rather doubt that, since they're basically unused at the moment...
(Reporter)

Comment 3

7 years ago
(In reply to comment #1 and comment #2)
> Or is this really about the case of <video> and <audio> elements?  I rather
> doubt that, since they're basically unused at the moment...

Yeah, this was about <video> and <audio>. I realize that it’s impossible to detect if Flash or another plugin is playing audio or video.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This sort of thing is something Blair and I have discussed as well, specifically being able to scan your tabs to see which one is making sound.  It might be nice to consider the best way for various chrome UI to indicate this--this bug is one of many I can imagine.
It would be great if we could do this, but I think we'd really need to make it work for any audio source. Users won't really care _how_ the sound is being, and so a feature that only works for HTML5 media is going to appear broken.
I hear what you're saying, but I worry about gating ourselves on this.  Isolating sound-per-tab with flash isn't going to work, and I wonder if we can entice people to <audio> and <video> by giving them incentives like this fix.  I suspect that improving the experience of using these html methods vs. flash will help wean people (devs) over.
Sure, we could add enticements like "if you use HTML5 media, the user gets cool media controls in the tab" or somesuch. That's a separate issue.

But for the use case of "help user figure out which tab is making noise", this would just reflect poorly on the browser. (Especially since a common source of noise is annoying Flash ads)
Yes, I agree with you, which is why I was jumping into this bug, which seems to be about <audio> and <video> specifically.
(In reply to comment #1)
> If the audio is playing through flash or some other plug-in, then we just don't
> have the information that it's playing audio.  It's talking directly to the OS
> audio services, completely bypassing our code.  So we can't indicate that it's
> playing audio... we don't know that it is.

This is related to bug 593897; apparently most of the Chinese web browsers actually hook the Windows sound APIs in order to enable a "global browser mute", and it's quite a popular feature. If we did that, we'd know whether audio was playing using the hooked APIs.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 486262
You need to log in before you can comment on or make changes to this bug.