Rename function MaybeNotifyMediaBlocked() to MaybeNotifyMediaBlockStart().
MozReview-Commit-ID: CJyWiKKkpwd
--HG--
extra : rebase_source : cc9c86f366f580830fec47006da686feeed4030b
In present design, the tab would hide the unblocking icon when receives
the audio-playback event, but it means we can't hide the icon if the media isn't
audible.
For example, we won't show the unblocking icon for audio with audio track, but
we show the icon for audio with silent audio track which can only be detected
after starting decoding.
In this case, we can't receive the audio-playback after resuming that media.
Therefore, we should dispatch the different event to notify tab UI that the
tab has already been resumed.
MozReview-Commit-ID: 3xCWQU7nVCl
--HG--
extra : rebase_source : b5f8855b17664bb1cc2b485f1d85120c0939931f
Rename function MaybeNotifyMediaBlocked() to MaybeNotifyMediaBlockStart().
MozReview-Commit-ID: CJyWiKKkpwd
--HG--
extra : rebase_source : 63cb95fd65565bfe872546dd2b4cf5c21d57af47
In present design, the tab would hide the unblocking icon when receives
the audio-playback event, but it means we can't hide the icon if the media isn't
audible.
For example, we won't show the unblocking icon for audio with audio track, but
we show the icon for audio with silent audio track which can only be detected
after starting decoding.
In this case, we can't receive the audio-playback after resuming that media.
Therefore, we should dispatch the different event to notify tab UI that the
tab has already been resumed.
MozReview-Commit-ID: 3xCWQU7nVCl
--HG--
extra : rebase_source : 7b4214f1f552ba75da94e4bb1795178983af20f7
In previous patch, we modify the behavior of nsDocument, now it would only resume
window when document has active media components.
However, it causes another issue. If the tab really goes to foreground, but
there is no active media component, the tab would still be blocked and it won't
be resumed anymore.
Therefore, we need to resume it by ourself if the tab is on the foreground but
doesn't be resumed yet.
MozReview-Commit-ID: EdnQ7sRkSJK
--HG--
extra : rebase_source : c2ab932cc3134531e5c49581c5e63b4aabef6ca4
For the first pinned tab, it would be set to visible first and then set to
invisible if there exists other tabs after restarting the whole browser.
If the tab is set to visible, we would activate the media component (set the
|mMediaSuspended| in outer window to none-suspend). In this case, the first
pinned tab would be set to visible briefly, but it doesn't mean the tab is in
the foreground, it's just how DOM manage the tab's visibility.
In that moment, none of the media component has been created yet. Therefore, we
would only activate the media component after the audio channel service exists.
MozReview-Commit-ID: 1FgdMq84yWX
--HG--
extra : rebase_source : d5d7568b9f4bfddf2abd0b2c2a4e9391a856882b
We need to notify tabbrowser about media-blocking so that we can show the unblocking tab icon.
See bug1308399 for more UX details.
MozReview-Commit-ID: E25lEhZLCZk
--HG--
extra : rebase_source : dcb6cb520bb0983010dfcc728f7251994a886612
In general, the audio competing should only be for audible media and it helps user can focus on one media at the same time. However, we hope to treat all media as the same in the mobile device.
First reason is we have media control on fennec and we just want to control one media at once time. Second reason is to reduce the bandwidth, avoiding to play any non-audible media in background which user doesn't notice about.
MozReview-Commit-ID: yB3181cmVE
--HG--
extra : rebase_source : 0f7bc1d4e9fc3f68e2085f59eb0a313d44a1c058
CLOSED TREE
Backed out changeset e716d9ac93d7 (bug 1214148)
Backed out changeset 5f693237c8c1 (bug 1214148)
Backed out changeset 3a4865d79416 (bug 1214148)
This is built on top of the AudioChannel infrastructure. This patch does not
actually implement the capture, it just does the plumbing to be able to notify
all HTMLMediaElement/AudioContext for a document.
This is built on top of the AudioChannel infrastructure. This patch does not
actually implement the capture, it just does the plumbing to be able to notify
all HTMLMediaElement/AudioContext for a document.
This is built on top of the AudioChannel infrastructure. This patch does not
actually implement the capture, it just does the plumbing to be able to notify
all HTMLMediaElement/AudioContext for a document.
Right now this function is called after the XPCOM component manager is
shut down, so it can never remove any observers. It's better to do this
work in response to xpcom-shutdown while we still have a component
manager to be able to clean up after ourselves properly.
Right now this function is called after the XPCOM component manager is
shut down, so it can never remove any observers. It's better to do this
work in response to xpcom-shutdown while we still have a component
manager to be able to clean up after ourselves properly.