The patch also removes the ignoreRootScrollFrame option from
APZCCallbackHelper::DispatchMouseEvent() altogether as it is
no longer used.
Depends on D75735
Differential Revision: https://phabricator.services.mozilla.com/D75736
This patch will do :
- use `MediaSampleMarkerPayload` to replace `VideoFrameMarkerPayload`
The advantage of doing so :
- after finishing a support for `MediaSampleMarkerPayload` in profiler front-end side, we can show the sample's start and end time when hovering on the marker icon.
Differential Revision: https://phabricator.services.mozilla.com/D75469
This patch will do :
- add `Media` markers in related codes
- implement `MediaSampleMarkerPayload` to record the media sample
The advantage of doing so :
- using markers can help us know what happens on the media by a glance without expanding the call stack
- adding sample markers allows us compare the speed of decoding sample in `MediaDecoderStataMachine` and rendering sample in `VideoSink`
Differential Revision: https://phabricator.services.mozilla.com/D74174
This patch will do :
- create a sub-category `Cubeb`
- add `Cubeb` profiling labels in related codes
The advantage of doing so :
- allow us to know the percentage of time respectively we spend on cubeb and non-cubeb codes
More details :
The profiling code would include `<atomic>` which is C++ only, so I can't use the label in `cubeb.c` directly. Instead, I add labels on the `AudioStream` and `AudioCallbackDriver` where we would call cubeb related methods.
Differential Revision: https://phabricator.services.mozilla.com/D74172
This patch will do :
- create a profiling category `Media`
- add `Media` profiling labels in related codes
The advantage of doing so :
- allow us to easily see what operations are related to media playback from the profiled report
More details :
According to the description in the `ProfilingCategory.h`, `topmost profiler label frame in the label stack determines the category pair of that stack`. Therefore, most labels I added are the first task would run on the thread, in order to ensure all its following tasks can be marked as the media playback label as well.
Differential Revision: https://phabricator.services.mozilla.com/D74171
Instead move the check to the focus manager, more similar to how
focus-visible works.
Now nsGlobalWindowInner::ShouldShowFocusRing means "Should we show focus
ring for anything in this window", that is: Have we keyboard-navigated
in this window, or do we have a pref that says that we should always
show focus rings.
Fix some callers appropriately (some of them that were not properly
accounting for the element being focused in the first place...).
Differential Revision: https://phabricator.services.mozilla.com/D75504
ChromeUtils::requestProcInfo was dropping thread names for the process process. This patch restores them and tests that at least *one* thread is named. Unfortunately, at the time of this writing, we cannot assume that *all*
threads are named. Investigation pending.
Differential Revision: https://phabricator.services.mozilla.com/D75420
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 :
- add test cases
- introduce the test-only notification `media-displayed-metadata-changed` when the event source updates its metadata
The advantage of doing so :
- increase test coverage
Differential Revision: https://phabricator.services.mozilla.com/D72501
This patch will do :
- play media from different frame, rather than alway playing media from the main frame
The advantage of doing so :
- to make the media session in child frame become the active media session because that can only be the context with the audio focus
Differential Revision: https://phabricator.services.mozilla.com/D72500
This patch will do :
- remove out-of-date test that uses the previous implementation of determining the active media session
The advantage of doing so :
- prevent the failure causing by out-of-date test
Differential Revision: https://phabricator.services.mozilla.com/D72499
This patch will do :
- listen to the playback change from the event source directly
The advantage of doing so :
- more close to the real situation because the event source is where we decide the information that should be displayed the virtual control interface
Differential Revision: https://phabricator.services.mozilla.com/D72498
This patch will do :
- postpone the timing of activating the media controller. Activate the controller after it first time becomes audible.
The advantage of doing so :
- prevent setting incorrect media metadata before the controller becomes audible
---
More details about this change :
The active media session would be chose after the context owns the audio focus. Therefore, if we would like to get the correct metadata from the media session, we should postpone the timimg of activate controller and wait until we decide the active media session then we can get the correct metadata.
Differential Revision: https://phabricator.services.mozilla.com/D72497
This patch will do :
- using the audio focus to decide which media session is the active media session. That is a recommend way of the spec [1].
The advantage of doing so :
- prevent to routing media control keys to incorrect media session
- prevent showing the incorrect metadata on the virtual control interface
[1] https://w3c.github.io/mediasession/#active-media-session
Differential Revision: https://phabricator.services.mozilla.com/D72496
This patch will do :
- introduce a concept `audio focus` among different contexts within a tab
- determine the audio focus owner when the context becomes audible or the owner destroys
The advantage of doing so :
- the audio focus helps us to decide the active media session that would be implemented in the following part
More details:
When there are serveral contexts playing at the same time within a tab, we would like to determine an audible context from them to represent the tab, and that is the `audio focus` we mean in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D72495
This patch will do :
- replace the usage of `nsIDocShellTreeItem` with accessing the permission stored in the `WindowContext`
The advantage of doing so :
- determine the correct result for the blocking autoplay because `nsIDocShellTreeItem` is not always possible to be accessed after we enable Fission
More details :
When determining the result of the blocking autoplay, we would always check if the page is in user customized whitelist or blacklist in which we store sites domain, and the domain we check is always the top level window's domain.
For example, a page (foo.com) has an iframe (bar.com), and we allow `foo.com` to autoplay. Then, if the iframe `bar.com` wants to autoplay from this page, we would also allow it because the main page is `foo.com`.
However, the current way of checking `nsIDocShellTreeItem` is not Fission compatible, because you can't access `nsIDocShellTreeItem` in the different process if the iframe is cross-origin. Therefore, we should remove its usage.
Differential Revision: https://phabricator.services.mozilla.com/D74512
This patch will do :
- create a sync field `AutoplayPermission` on WindowContext
- update the field whenever site's the autoplay permission changes
The advantage of doing so :
- to help determine the result of the blocking autoplay correctly.
More details :
As the field would be automatically synced between processes, then we can know the correct site's autoplay permission for the whole page even if we're in the different process if the iframe is in different origin after we enable Fission.
Differential Revision: https://phabricator.services.mozilla.com/D74511
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 :
- add test cases
- introduce the test-only notification `media-displayed-metadata-changed` when the event source updates its metadata
The advantage of doing so :
- increase test coverage
Differential Revision: https://phabricator.services.mozilla.com/D72501
This patch will do :
- play media from different frame, rather than alway playing media from the main frame
The advantage of doing so :
- to make the media session in child frame become the active media session because that can only be the context with the audio focus
Differential Revision: https://phabricator.services.mozilla.com/D72500
This patch will do :
- remove out-of-date test that uses the previous implementation of determining the active media session
The advantage of doing so :
- prevent the failure causing by out-of-date test
Differential Revision: https://phabricator.services.mozilla.com/D72499
This patch will do :
- listen to the playback change from the event source directly
The advantage of doing so :
- more close to the real situation because the event source is where we decide the information that should be displayed the virtual control interface
Differential Revision: https://phabricator.services.mozilla.com/D72498
This patch will do :
- postpone the timing of activating the media controller. Activate the controller after it first time becomes audible.
The advantage of doing so :
- prevent setting incorrect media metadata before the controller becomes audible
---
More details about this change :
The active media session would be chose after the context owns the audio focus. Therefore, if we would like to get the correct metadata from the media session, we should postpone the timimg of activate controller and wait until we decide the active media session then we can get the correct metadata.
Differential Revision: https://phabricator.services.mozilla.com/D72497
This patch will do :
- using the audio focus to decide which media session is the active media session. That is a recommend way of the spec [1].
The advantage of doing so :
- prevent to routing media control keys to incorrect media session
- prevent showing the incorrect metadata on the virtual control interface
[1] https://w3c.github.io/mediasession/#active-media-session
Differential Revision: https://phabricator.services.mozilla.com/D72496
This patch will do :
- introduce a concept `audio focus` among different contexts within a tab
- determine the audio focus owner when the context becomes audible or the owner destroys
The advantage of doing so :
- the audio focus helps us to decide the active media session that would be implemented in the following part
More details:
When there are serveral contexts playing at the same time within a tab, we would like to determine an audible context from them to represent the tab, and that is the `audio focus` we mean in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D72495
Instead move the check to the focus manager, more similar to how
focus-visible works.
Now nsGlobalWindowInner::ShouldShowFocusRing means "Should we show focus
ring for anything in this window", that is: Have we keyboard-navigated
in this window, or do we have a pref that says that we should always
show focus rings.
Fix some callers appropriately (some of them that were not properly
accounting for the element being focused in the first place...).
Differential Revision: https://phabricator.services.mozilla.com/D75504
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75380
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75378
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75374
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75373