Bug 1192818 - part2 : only dispatch DOMAudioPlaybackStarted when there is audible sound.
The DOMAudioPlaybackStarted event would affect the tabbrowser's attribute,
"soundPlaying", and this attribute should indicate whether the tab is audible or not. However, in present codebase, even the tab has "soundplaying", it doens't mean
the tab has audible sound, you need to check extra attribute, "muted".
After applying this patch, tabbrowser can only own one of the attributes ("soundplaying"
or "mute"). These attributes won't exist at the same time, so we can easily know
whether the tab is audible by checking "soundPlaying".
Let's see an example,
step1. playing a playing audio
- tab owns "soundPlaying"
step2. mute the tab
- tab owns "muted"
step3. stop audio
- tab owns "muted"
step4. replay the audio
- tab owns "muted"
step5. unmute the tab
- tab owns "soundPlaying"
step6. stop audio
- tab owns ""
MozReview-Commit-ID: EEKEbAVzsVm
--- a/toolkit/content/widgets/browser.xml
+++ b/toolkit/content/widgets/browser.xml
@@ -692,16 +692,19 @@
<!-- Obsolete name for blockedPopups. Used by android. -->
<property name="pageReport"
onget="return this.blockedPopups;"
readonly="true"/>
<method name="audioPlaybackStarted">
<body>
<![CDATA[
+ if (this._audioMuted) {
+ return;
+ }
let event = document.createEvent("Events");
event.initEvent("DOMAudioPlaybackStarted", true, false);
this.dispatchEvent(event);
]]>
</body>
</method>
<method name="audioPlaybackStopped">