The telemetry probe, which is related with `mDocTreeHadPlayRevoked`, has already been removed, so we don't need these code anymore.
Differential Revision: https://phabricator.services.mozilla.com/D83163
Whenever the audible state changes, we should always store the latest state but only notify the change after playing starts.
Differential Revision: https://phabricator.services.mozilla.com/D83549
The MediaStreamRenderer handles the AudioOutput of an HTMLMediaElement. it register/unregister the AudioOutput according to the rendering status. The sink-change follows the logic of AudioOutput thus it has been moved in it.
The previous way created an error when the element had been muted and the sink had been changed before the source MediaStream was attached to the element. The error occured because it was possible, the same entry to be registered more than once in the AudioOutput's list, which resulted in the track to be unmuted when it should not.
Differential Revision: https://phabricator.services.mozilla.com/D82529
When aborting the current load, media element is undoubtedly inaudible. Therefore, we should reset its audible state in order to keep the audible state correct. That can help us show the sound indicator on the tab bar correctly.
Differential Revision: https://phabricator.services.mozilla.com/D81631
At the end of `HTMLMediaElement::SetSrcMediaStreamSink` a redirection of MozPromises, from `GenericPromise::AllPromiseType` to `GenericPromise` is taking place. However, this is not necessary since this is an internal method and the returned value of the promise is not useful. Thus the `GenericPromise::AllPromiseType` can be returned directly and avoid the extra thread dispatch.
Differential Revision: https://phabricator.services.mozilla.com/D80908
This patch would
- build the relationship between a media element and the media controller when media finishes loading, instead of building that after starting playing media
The advantage of doing this is
- the prework of being able to control media before media starts playing
Differential Revision: https://phabricator.services.mozilla.com/D79234
This patch would
- move the mechanism of creating a stop timer from media element to media controller
The advantage of doing this is
- to remove redundant timers in the content process, because we only need to maintain one global timer for a whole tab
Differential Revision: https://phabricator.services.mozilla.com/D79233
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
The SetSinkId method of HTMLMediaElement has been enhanced to handle the sink change when the element is sourced with a MediaObject through the srcObject attribute. It makes use in the corresponding method of AudioStreamTrack taking into account the AudioOutput and Volume that has to be removed and re-added to the right track.
Differential Revision: https://phabricator.services.mozilla.com/D77809
This patch will
- remove `MediaControlKeysEvent` and use `MediaControlKey` to replace it
- rename names for all `MediaControlKey` related methods, functions, classes and descriptions
The advantage of doing so are
- remove the duplicated type so that we only need to maintain `MediaControlKey`
Differential Revision: https://phabricator.services.mozilla.com/D78140
This patch will
- make `ContentMediaAgent` inherit from `IMediaInfoUpdater`
- move `MediaPlaybackState` and `MediaAudibleState` to `MediaPlaybackStatus.h`
The advantage of doing so are
- to force all methods which are related with updating information from content process to chrome process to be manged by `IMediaInfoUpdater`. It can help us only put the descriptive comment for methods on one place. (on `IMediaInfoUpdater`)
Differential Revision: https://phabricator.services.mozilla.com/D77196
Feeding a media element with the captured stream from the same media element does not make sense. Currently the spec does not mention anything about it. I'll clarify the case in the spec. In the meantime, when a cycle is detected, the setting of the `srcObject` is ignored and a warning is produced in the console.
Differential Revision: https://phabricator.services.mozilla.com/D76821
This patch will do :
- update the media status when media changes its owner browsing context
The advantage of doing so :
- make the media status in `ContextMediaInfo` correcly
More details :
`ContextMediaInfo` stores the media status of each browsing context, but actually the media doesn't always need to stay in one browsing context. We can move it to other browsing contexts (iframe) by appending it to other browsing context's document body.
For example, in [1], we move the video from the main frame to another iframe.
Therefore, when we move the media to a new browsing context, we should also update its media status (controlledMedia/playing/audio number) for its previous owner browsing context.
[1] https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/embedded-content/media-elements/playing-the-media-resource/pause-move-to-other-document.html
Differential Revision: https://phabricator.services.mozilla.com/D75477
This patch will do :
- remove audible check from the logic of registering controller
- include audio channel affect on the media element's audible state
The advantage of doing so :
- it can help to reduce the intermittent failure during testing by earlier hooking media elements in the content process to the media controller in the chrome process
More details :
In D72497, we have added the audible check to postpone the activation of the media controller, which would ensure that we only control media after it become audible. Therefore, we can remove the previous implementation which we use to achieve that in media element.
When having that audible check in media element, it would postpone the timing of adding media element to `ContentMediaController` that causes some intermitent failures when I was writing test for bug1633565. When removing those checks, we can ensure that the media element would have always been added into `ContentMediaController` after calling `video.play()`. If the element haven't been added into `ContentMediaController`, then it would miss to handle the media key events when test generates a fake media key event, which causes an intermitent failure.
Differential Revision: https://phabricator.services.mozilla.com/D73335
This patch will do :
- update the media status when media changes its owner browsing context
The advantage of doing so :
- make the media status in `ContextMediaInfo` correcly
More details :
`ContextMediaInfo` stores the media status of each browsing context, but actually the media doesn't always need to stay in one browsing context. We can move it to other browsing contexts (iframe) by appending it to other browsing context's document body.
For example, in [1], we move the video from the main frame to another iframe.
Therefore, when we move the media to a new browsing context, we should also update its media status (controlledMedia/playing/audio number) for its previous owner browsing context.
[1] https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/semantics/embedded-content/media-elements/playing-the-media-resource/pause-move-to-other-document.html
Differential Revision: https://phabricator.services.mozilla.com/D75477
This patch will do :
- remove audible check from the logic of registering controller
- include audio channel affect on the media element's audible state
The advantage of doing so :
- it can help to reduce the intermittent failure during testing by earlier hooking media elements in the content process to the media controller in the chrome process
More details :
In D72497, we have added the audible check to postpone the activation of the media controller, which would ensure that we only control media after it become audible. Therefore, we can remove the previous implementation which we use to achieve that in media element.
When having that audible check in media element, it would postpone the timing of adding media element to `ContentMediaController` that causes some intermitent failures when I was writing test for bug1633565. When removing those checks, we can ensure that the media element would have always been added into `ContentMediaController` after calling `video.play()`. If the element haven't been added into `ContentMediaController`, then it would miss to handle the media key events when test generates a fake media key event, which causes an intermitent failure.
Differential Revision: https://phabricator.services.mozilla.com/D73335
This patch will do :
- remove audible check from the logic of registering controller
- include audio channel affect on the media element's audible state
The advantage of doing so :
- it can help to reduce the intermittent failure during testing by earlier hooking media elements in the content process to the media controller in the chrome process
More details :
In D72497, we have added the audible check to postpone the activation of the media controller, which would ensure that we only control media after it become audible. Therefore, we can remove the previous implementation which we use to achieve that in media element.
When having that audible check in media element, it would postpone the timing of adding media element to `ContentMediaController` that causes some intermitent failures when I was writing test for bug1633565. When removing those checks, we can ensure that the media element would have always been added into `ContentMediaController` after calling `video.play()`. If the element haven't been added into `ContentMediaController`, then it would miss to handle the media key events when test generates a fake media key event, which causes an intermitent failure.
Differential Revision: https://phabricator.services.mozilla.com/D73335
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
This is in preparation for running the tail dispatcher off
nsIThreadObserver callbacks, which only work during regular
event processing.
Differential Revision: https://phabricator.services.mozilla.com/D72264
This patch will do :
- rename `ControlledMediaState` to `MediaPlaybackState`
- rename the related functions
The advantage of doing so :
- more consistent with `MediaAudibleState`
Differential Revision: https://phabricator.services.mozilla.com/D72060
This patch will do :
- replace `boolean` with enum class `MediaAudibleState`
The advantage of doing so :
- It's easier to understand what actually meaning of the parameter we set
Differential Revision: https://phabricator.services.mozilla.com/D72058
This patch will do :
- use current broswing context as a parameter when propagate state change to the chrome process.
The advantage of doing so :
- the chrome process can know which browsing context the state change actually comes from.
---
More details about this change :
Currently, when we propagate any controlled media related states, we would find the top level browsing context first, then pass it through IPC in order to get the correct media controller in the chrome process. However, we have implemented [1] which can find the correct media controller even if we are not passing the top level browsing context.
In addition, in bug1627999, we would like to know which browsing context those states come from. Therefore, we should replace the top browsing context with the current browsing context where controlled media exists.
[1] https://searchfox.org/mozilla-central/rev/41c3ea3ee8eab9ce7b82932257cb80b703cbba67/docshell/base/CanonicalBrowsingContext.cpp#511-515
Differential Revision: https://phabricator.services.mozilla.com/D72056
This patch will do :
- remove the inheritance relationship for `ContentControlKeyEventReceiver` and `ContentMediaAgent` and manually implement the methods we need
- `MediaControlEventListener` will inherit from `ContentControlKeyEventReceiver` directly
The advantage of doing so :
- increase the flexibilty of modification of `ContentMediaAgent` and those modification won't affect other classes inherited from `MediaControlKeysEventListener`
---
More details about this change :
As we would like to extend the class `ContentMediaAgent` and allow the `ContentMediaController` to call its extended method, but if we want to do so in current implementation, the extended method would also affect other classes inherited from `MediaControlKeysEventListener` and that is something we don't want to see.
Considering that, I decided to decouple the inheritance relationship and manually create the function I need (which will be implemented in the next patch)
Differential Revision: https://phabricator.services.mozilla.com/D72054
After applying this patch,
- notify `inaudible` state only if we already notified `audible` state before
- update `inaudible` state when audible media is paused
Therefore, in the media controller side, it would always see a pair of `audible/inaudible` notifications like what we do for the pair of `ControlledMediaState::ePlayed/ePaused` notifications. That can help us implement a way of maintaining a detailed counting about how many media is audible in bug1627999.
Differential Revision: https://phabricator.services.mozilla.com/D71429
There is actually possible to start the listener already while running `SuspendOrResumeElement()`, so we should remove the assertion and use a check instead.
Eg. JS can call `play()`, which would start the listener, before we run this method. This situation can be found when browsing Youtube on the GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D69673
When the docShell's `SuspendMediaWhenInactive` flag is true, no media should be allowed to start playing. Therefore, we add a check in `Play()`, `CanActivateAutoplay()` to prevent media from playing. In addition, we should also prevent the audio channel agant from starting.
Differential Revision: https://phabricator.services.mozilla.com/D69672
If docShell's `SuspendMediaWhenInactive` is true, then we should suspend or resume the media element according to the docshell active state when the docshell changes it active state.
Differential Revision: https://phabricator.services.mozilla.com/D69671
AutoEnter was an attempt around a race between AbstractThread and MessageLoopAbstractThreadWrap that would cause AbstractThread::GetCurrent() to return an incorrect value. MessageLoopAbstractThreadWrapper is no more and as such AutoEnter is no longer required.
Differential Revision: https://phabricator.services.mozilla.com/D71279
There is actually possible to start the listener already while running `SuspendOrResumeElement()`, so we should remove the assertion and use a check instead.
Eg. JS can call `play()`, which would start the listener, before we run this method. This situation can be found when browsing Youtube on the GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D69673
When the docShell's `SuspendMediaWhenInactive` flag is true, no media should be allowed to start playing. Therefore, we add a check in `Play()`, `CanActivateAutoplay()` to prevent media from playing. In addition, we should also prevent the audio channel agant from starting.
Differential Revision: https://phabricator.services.mozilla.com/D69672
If docShell's `SuspendMediaWhenInactive` is true, then we should suspend or resume the media element according to the docshell active state when the docshell changes it active state.
Differential Revision: https://phabricator.services.mozilla.com/D69671
