As we would show delay media playback icon for `eNotAudible` and `eMaybeAudible`, we should call `AudioChannelWindow::AudioAudibleChanged()` when we register the agent in order to notify a delaying start.
In the past, as we use `AudioChannelWrapper` to handle delaying, which would call `HTMLMediaElement::AudioChannelWrapper::WindowSuspendChanged()` immediately when we delay autoplay, and finally triggers `AudioChannelWindow::AudioAudibleChanged()` to notify sending block-start event. It's very unclear, so we should set it in the beginning if we have already know the audible state of delayed media.
Differential Revision: https://phabricator.services.mozilla.com/D44748
--HG--
extra : moz-landing-system : lando
As we have another usage to know whether media is audible or not, we remove this function from AudioChannelWrapper and make it as media element's function.
In addition, it also makes sense to have this function for media element, because the result is decided by media element's own attributes.
Differential Revision: https://phabricator.services.mozilla.com/D44744
--HG--
extra : moz-landing-system : lando
To hide some functions from `AudioChannelAgent` to avoid an access from `AudioChannelAgentCallback` (eg. media element, audio destination node...), and only allow `AudioChannelService` to use those functions.
Differential Revision: https://phabricator.services.mozilla.com/D45755
--HG--
extra : moz-landing-system : lando
Now other `WindowXXXChanged()` would receive the change directly from their input parameter, we should make `WindowVolumeChanged()` consistent with them, instead of asking `AudioChannelService` again.
Differential Revision: https://phabricator.services.mozilla.com/D45754
--HG--
extra : moz-landing-system : lando
After applying patch4, now we would pull the change from `AudioChannelService` everytime after starting the agent, so we don't need to rely on letting `NotifyStartedPlaying()` to modify the config and use it to update our state.
Differential Revision: https://phabricator.services.mozilla.com/D45753
--HG--
extra : moz-landing-system : lando
As we start audio capturing explicitly, we should also take responsibility to stop audio capturing when we don't need it.
We were hiding too many details on `AudioChannelAgent` before, which allow us hard to know who and where we handle audio capturing.
Differential Revision: https://phabricator.services.mozilla.com/D45752
--HG--
extra : moz-landing-system : lando
Instead of calling those callback functions seperately, we could provide a function to pull those changes at once after starting the agent.
In addition, `WindowXXXChanged` are callback functions of `nsIAudioChannelAgentCallback`, so they should only be called by `AudioChannelAgent`, to indicate receiving the change from `AudioChannelService`. We should not call them directly.
Differential Revision: https://phabricator.services.mozilla.com/D45751
--HG--
extra : moz-landing-system : lando
To hide some functions from `AudioChannelAgent` to avoid an access from `AudioChannelAgentCallback` (eg. media element, audio destination node...), and only allow `AudioChannelService` to use those functions.
Differential Revision: https://phabricator.services.mozilla.com/D45755
--HG--
extra : moz-landing-system : lando
Now other `WindowXXXChanged()` would receive the change directly from their input parameter, we should make `WindowVolumeChanged()` consistent with them, instead of asking `AudioChannelService` again.
Differential Revision: https://phabricator.services.mozilla.com/D45754
--HG--
extra : moz-landing-system : lando
After applying patch4, now we would pull the change from `AudioChannelService` everytime after starting the agent, so we don't need to rely on letting `NotifyStartedPlaying()` to modify the config and use it to update our state.
Differential Revision: https://phabricator.services.mozilla.com/D45753
--HG--
extra : moz-landing-system : lando
As we start audio capturing explicitly, we should also take responsibility to stop audio capturing when we don't need it.
We were hiding too many details on `AudioChannelAgent` before, which allow us hard to know who and where we handle audio capturing.
Differential Revision: https://phabricator.services.mozilla.com/D45752
--HG--
extra : moz-landing-system : lando
Instead of calling those callback functions seperately, we could provide a function to pull those changes at once after starting the agent.
In addition, `WindowXXXChanged` are callback functions of `nsIAudioChannelAgentCallback`, so they should only be called by `AudioChannelAgent`, to indicate receiving the change from `AudioChannelService`. We should not call them directly.
Differential Revision: https://phabricator.services.mozilla.com/D45751
--HG--
extra : moz-landing-system : lando
We use `NotifyMediaStarted()` and `NotifyMediaStopped()` to notify `MediaControlService` on parent process to start/stop a media controller, and use `NotifyMediaAudibleChanged()` to notify controller's audible state in order to request audio focus.
As our goal is to use media controller to control media element, not for web audio, web speech and other stuffs which also use audio channel agent.
Therefore, we should notify parent process to start/stop controller only for media element, instead of sending a notification in AudioChannelService because that would create media controller for all different consumers which uses audio channel agent.
Differential Revision: https://phabricator.services.mozilla.com/D45591
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
This patch updates BUG_COMPONENT for some dom/* and testing/web-platform/* files
Differential Revision: https://phabricator.services.mozilla.com/D28721
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This is a partial backout of Bug 1347791 part 3; a5fbb7e2d1d0.
We don't need to track in the front end code when a tab is foregrounded,
so we don't need to dispatch this message any more.
MozReview-Commit-ID: 6M0n9Ik65vE
--HG--
extra : rebase_source : 37ca839bdf9f323b11e010df643c31f895c602f5
As well as the obvious #ifdef stuff, the patch removes
TCPSocket::SetAppIdAndBrowser(), which means
{TCPSocketParent,TCPServerSocketParent}::{GetAppId,GetInIsolatedMozBrowser}()
can also be removed.
When the block stauts of the window was changed, we would notify front-end side
to update the vaule, so that we can save it for session restore.
MozReview-Commit-ID: FyclKmAxZHf
--HG--
extra : rebase_source : 5ac8bb9d82279074939caed53dd79c072a5097bc
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 : 4214c68b4c95df5c33bf1a68c9ffb84ee4c4d5aa
