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

Status: RESOLVED WORKSFORME

(WebExtensions :: General, defect, P5)

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 Bug Husbandry Bot]

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

Comment 12

[ariasuni]

I’m being blocked by this problem too, on Tab Center Reborn, which display an alternative vertical tab in a side panel.

One of my user like to have some pinned tabs muted, but she more often than not click on the muted indicator by mistake, and would prefer the icon being only visible when the tab could be producing sound. Obviously being it all the time is useless for her, she only wants to know if a tab is muted when it’s supposed to produce sound, and this is the only moment she needs quick access to the unmute feature.

Also, being consistent with Chrome is also important IMHO — no need to have yet another difference between WebExtensions implementations.

Anyway, if you finally decide you don’t want to change the current behavior, it would be better to make the docs unambiguous about what audible is really used for in different browsers.

Comment 13

[Richard Bloor]

Details about audible are updated on the tabs.Tab. As Andy is no longer around, who can I get to review?

Comment 14

[Rob Wu [:robwu]]

I just tested on Firefox 70.0.1 and Chrome 78.0.3904.108 on Linux, and the "audible" property is independent of the tab muting feature. This seems to always have been Firefox's behavior, ever since the API was introduced in bug 1238311 .

I've updated the documentation accordingly: https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/Tab$compare?locale=en-US&to=1592300&from=1592015

Richard, could you check which version looks better? If you think that the original version (before your edit) looks clearer, please revert to that version: https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/Tab$compare?locale=en-US&to=1592015&from=1584878

Comment 15

[Richard Bloor]

Thanks Rob, I've clarified the second sentence on the basis that if the tab is muted the user will hear nothing; the original sentence suggested muting may or may not stop sound from being produced. The new sentence reads "However, the user will not hear the sound if the tab is muted (see the mutedInfo property)." Please let me know if you happy with this change.

Comment 16

[Rob Wu [:robwu]]

Looks good, thanks!