Changes:
- remove code addressed by reviewer
- remove PContent.ipdl, PBrowser.ipdl, and ProcessPriorityManager code
that relates only to removed AudioChannelService methods
- correct test case listening to event from removed code
- remove useless test case files
MozReview-Commit-ID: I96nR8zTXJt
--HG--
extra : rebase_source : 127876c672744811c025ca55839ff2e8a06b1fce
Since now we move the block/resume logic to front-end side, we can remove
the changing from bug1319771 and other related bugs which are used to ensure the
pinned tab should be blocked successfully after session restore.
MozReview-Commit-ID: Ixe7tOvCEhv
--HG--
extra : rebase_source : 190e63b5df53c85f7282b5c2144ae7e7830d7ad3
When the agent is audible, we should check whether need to notify "blockStart"
immediately.
MozReview-Commit-ID: KmYLo9cEt4X
--HG--
extra : rebase_source : 71ad5892a30727f00fd3c764d83ade074bc85f15
When the agent is audible, we should check whether need to notify "blockStart"
immediately.
MozReview-Commit-ID: KmYLo9cEt4X
--HG--
extra : rebase_source : 5f29de593b85113001552ff0497621e603b40bc6
LazyLog can be used easily via adding the pref("logging.MODULE_NAME", DEBUG_LEVEL).
It's more convenient than PRLog.
MozReview-Commit-ID: T7uSxVAiN3
--HG--
extra : rebase_source : c0b8925e5c60353c690ca68b8fe4361b48a0f57a
The reason we introduced the IsServiceStarted(), check bug1338466 comment5 for
more details.
The patch1 introduces more robust way to check the alive media component, so
we can remove IsServiceStarted().
MozReview-Commit-ID: LIma8hZTuhA
--HG--
extra : rebase_source : 4687ef41cc765f4ffeb97aeac63b727897456167
In Fennec, the audio competiting is to stop the playing tab if there is new
incoming tab. We only implement the way to pause the tab, not including to resume
the tab, so we just need to run the audio competing related stuffs when the agent
is active.
MozReview-Commit-ID: 3F0M2jLw9VY
--HG--
extra : rebase_source : 59eeb82cdda4a976a078663557776f4bc3b5d27b
In websites such as Facebook Live, timeout chains are used to drive the
playback of a video or something similar in JavaScript. Throttling the
minimum timeout values a tab playing a video from such websites in the
background could make the timeout based scheduling of video playback to
not work correctly, and cause audio buffer under-runs that are audible.
In order to address this, other major browsers don't throttle timeouts
in tabs that are playing audio. This brings us to parity to other
browsers (even though we already do this for websites that use Web Audio
since we've had similar bug reports using the Web Audio API.)
The current audio agent setup that drives the tab audio notification
icons is currently tracking whether a Window is playing audio. We use
this setup to decide whether to throttle timeouts when a window goes
into background.
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
When user open new tab and then go to the pasted URL (which has autoplaying
media), the "play tab" icon would be displayed briefly, and then change to the
"mute tab" icon.
That is the media element starts before calling nsDocument::PageShow() which
would resume all blocked media in the tab. Before that moment, even the tab is
in the foreground, but we doesn't resume the media yet.
Therefore, we need to check the document's visibility by ourself, and only show
the "play tab" icon for the background blocked tab.
MozReview-Commit-ID: Eg2SD5kpG0j
--HG--
extra : rebase_source : ccf25537904a10e17de2e70650b62fac8f5a3434
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 order to refactor the blocking mechanism, we want to know the blocking state
before calling notifyStartedPlaying().
MozReview-Commit-ID: 3wa2M7qwUAm
--HG--
extra : rebase_source : d128463b7fd892b966d80d5b5f76537819f35bcf
Since the agent is created in beginning in patch1, we need another way to know
whether we have already called notifyStartedPlaying().
MozReview-Commit-ID: 5YNhwEl5Xfp
--HG--
extra : rebase_source : 6a2913e5d81591faf1a7383d9fcb9db2cf3f83d3
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
Use 'media-playback' event to control the media control interface on Fennec.
MozReview-Commit-ID: D8SU96RrkbQ
--HG--
extra : rebase_source : 16a13e3b1a450a2949cb62b77a53311797daaaf2
Ben Kelly
Ryan VanderMeulen
Bill McCloskey
Carsten "Tomcat" Book
Andrea Marchesini
btian
Alastor Wu
Michael Layzell
Iris Hsiao
Joel Maher
Tom Tromey
Ehsan Akhgari
Phil Ringnalda
Michelangelo De Simone
Wes Kocher
Nathan Froyd