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
--HG--
extra : rebase_source : 823d501e9162ae8b611f2e97dd763c1eec16c2cf
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 5RnyBRE73lQ
--HG--
extra : rebase_source : 40ad97cbf84da6f5d013d832cb12e3ed88473dfd
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: 50NorRbRIP
--HG--
extra : rebase_source : 8a06d1df7f4e3b974b18292944b19ada20eb655d
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 703JHj9dICT
--HG--
extra : rebase_source : ad2985bd14d6a9b91a73c0d4103aa51c4981124c
This is a terrible hack, asking input[type=range] in our video control
xbl binding content continue to handle mouse/touch event, even if the
event is being defaultPrevented by the content.
MozReview-Commit-ID: G1huxbS7oeq
--HG--
extra : rebase_source : 27153ce36e6883d947894da69dd9aca47965e99b
This changes the `relatedBrowser` property which held a <xul:browser> to the
more explicit `sameProcessAsFrameLoader` which takes an nsIFrameLoader.
This clarifies the purpose of the property and also (by switching to the frame
loader) makes it easier to set in some contexts.
MozReview-Commit-ID: LnEvSP8zkto
--HG--
extra : rebase_source : f9f4c07995ef39f1ccd5042e9ae3df37879423b6