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
Per https://html.spec.whatwg.org/#selector-read-write:
> The :read-write pseudo-class must match any element falling into one
> of the following categories [...]:
>
> * input elements to which the readonly attribute applies, and that
> are mutable (i.e. that do not have the readonly attribute
> specified and that are not disabled)
>
> * textarea elements that do not have a readonly attribute, and
> that are not disabled.
>
> * elements that are editing hosts or editable and are neither
> input elements nor textarea elements.
This fixes the `:disabled` bits.
This matches Safari behavior and the spec, but not Chrome, which has our
behavior.
Fix the WPT, which had multiple issues, as :read-only is defined to be
just the opposite of :read-write. This will pass as soon as I unprefix
the pseudo-class.
Differential Revision: https://phabricator.services.mozilla.com/D75230
In RFP mode, canvas image extraction leads to an all-white image, replace that
with a random (sample 32 bytes of randomness and fill the buffer with that)
'poison pill'. This helps defeat naive fingerprinters by producing a random
image on every try. This feature is toggled using a new, default on, pref
`privacy.resistFingerprinting.randomDataOnCanvasExtract`.
Updated `browser_canvas_fingerprinting_resistance.js` to test this new feature
as well.
Updates and replaces D66308.
Differential Revision: https://phabricator.services.mozilla.com/D72716
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
URLBarInput relies on it being non-null when created, but that may not
happen if we construct frames lazily without this patch.
Differential Revision: https://phabricator.services.mozilla.com/D74891
This should make it easier to write tests for race-conditions, as
the resolving value now indicates which event was received.
This required updating a test which for some reason asserted
undefined being the resolving value, as a way of "testing" if the
Promise resolved at all. Since await already throws Errors when it
is rejected, and the test throws a timeout if it doesn't resolve in
time, this assertion was removed. It did not add any value.
Differential Revision: https://phabricator.services.mozilla.com/D74124
Modify PresState's string variant to also store whether the last change was
interactive, and preserve that property when saving and restoring state.
Differential Revision: https://phabricator.services.mozilla.com/D73920
In RFP mode, canvas image extraction leads to an all-white image, replace that
with a random (sample 32 bytes of randomness and fill the buffer with that)
'poison pill'. This helps defeat naive fingerprinters by producing a random
image on every try. This feature is toggled using a new, default on, pref
`privacy.resistFingerprinting.randomDataOnCanvasExtract`.
Updated `browser_canvas_fingerprinting_resistance.js` to test this new feature
as well.
Updates and replaces D66308.
Differential Revision: https://phabricator.services.mozilla.com/D72716
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
referrerpolicy and crossorigin changes were handled in
AfterMaybeChangeAttr, but were only handling the case where the
attribute changed (that is, the AfterSetAttr caller). However
AfterSetAttr only calls AfterMaybeChangeAttr if there's a new value,
which means that we don't handle attribute removal.
So their handling can just move to AfterSetAttr, and we can simplify
AfterMaybeChangeAttr to just deal with src changes which is what it was
intended to deal with anyhow.
Differential Revision: https://phabricator.services.mozilla.com/D73619
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
Even in comm-central and BlueGriffon, `nsISelectionController::*ForDelete()`
are not used. Therefore, we can remove them safely.
Differential Revision: https://phabricator.services.mozilla.com/D72296
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 "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
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
