1379858 - tabs.Tab.audible returns incorrect result for muted tabs that are playing sound

Status: NEW

Description

[Trevor Rowbotham [:rowbot]]

The |audible| attribute reports false when the tab is muted and playing sound, however, according to [1], |audible| should be true if the tab is muted and is playing sound.

STR:
1) Create a webextension that attaches a listener for browser.tabs.onUpdated.
2) Open any YouTube video.
3) Mute the tab.

An onUpdated event will be received immediately |changeInfo.audible = undefined| and |changeInfo.mutedInfo.muted = true|.  Then, approximately 3 seconds later another onUpdated event will be received with the |changeInfo.audible = true|.

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/Tab

Comment 1

[Trevor Rowbotham [:rowbot]]

I forgot to add that this is on Windows 10 using the latest 64bit Nightly.

Comment 2

[Trevor Rowbotham [:rowbot]]

This looks like a regression. It is working on release in my Linux VM, but is broken in Nightly on my Linux VM. I'll try to find a regression range tomorrow.

Comment 3

[Trevor Rowbotham [:rowbot]]

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1ac7781188d2977c0b0ab00746d67e24ca04e608&tochange=8ceb1224123129e5cd6cd8e14dcfdf2f7e549cb8

Bug 1192818 seems to be the culprit here. Alistor, it looks like your patch regressed this.

Comment 4

[Alastor Wu [:alwu]]

Hi, Baku,
Should we need to follow this document [1]?
For me, I would like to keep |audible| as a variable which can actually know whether the tab is producing audible sound or not.
Thanks!

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/Tab

Comment 5

[Andrea Marchesini [:baku]]

Interesting point. To me the current behavior is better, but we should also check what chrome does.
About the muting, there is also tab.mutedInfo.
Let's ask Andy if we can change the behavior of this attribute, or update the documentation.

Comment 6

[Trevor Rowbotham [:rowbot]]

Both Chrome and Opera follow the documentation at https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/Tab in regards to the |audible| attribute. So, I don't think we can change what it does if we want to be have parity with the other browsers here. Edge does not currently support the |audible| attribute.

Comment 7

[Andy McKay]

Sorry, I find comment 0 a little confusing:

"according to [1], |audible| should be true if the tab is muted and is playing sound."

then:

"Then, approximately 3 seconds later another onUpdated event will be received with the |changeInfo.audible = true|."

It appears to be doing what the docs say? Is the first event: "|changeInfo.audible = undefined|" the problem?

If you are on Windows, could you try going to about:config and flipping the pref extensions.webextensions.remote to false and re-testing please?

Comment 8

[Trevor Rowbotham [:rowbot]]

Sorry, that was a mistake on my part, |audible| is false in the second event. 

Flipping extensions.webextensions.remote to false has no effect on the result.

Comment 9

[Andy McKay]

I can reproduce and I agree with you Trevor, I think it makes sense for a WebExtensions API to know that the tab is producing sound and the developer can check to see if its muted or not.

Comment 10

[Alastor Wu [:alwu]]

Sorry for my late reply.
Although this issue is easy to be fixed, but I still not sure whether we need to change the behavior of this attribute as same as Chrome's. The reasons are on the following.

(1) Meaning
Literally, the |audible| should reflect the actual audible state, means user can hear the sound or not. It still makes no sense for me if we can't hear the sound but the value is true.

(2) Muted possibility
We provide easy way to mute the sound via clicking the sound speaker indicator, but Chrome doesn't. You need to mute it via the context menu (more complex), their speaker indicator doesn't support for muting. That means we have higher possibility to be in that state (media is playing, but being muted). As (1) said, I think it's not reasonable to its naming.

(3) Speaker indicator usage 
See [1], it's not just about the sound, it's also related with the display state of their speaker audio indicator.

> Whether the tab has produced sound over the past couple of seconds (but it might not be heard if also
> muted). Equivalent to whether the speaker audio indicator is showing. 

From this sentence, if it references to the display state of speaker audio indicator, it's exactly what we do now. We only shows the speaker audio indicator when the tab really *AUDIBLE*.

[1] https://developer.chrome.com/extensions/tabs#type-Tab

---

I'll prefer to discuss this attribute with Chrome's guys.

Comment 11

[Firefox Product Integrity Bug Husbandry Bot (contact :emceeaich)]

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958