This patch tries to dispatch ePointerRawUpdate with
PresShell::EventHandler::DispatchPrecedingPointerEvent as same as usual
pointer events.
For using the path, this patch adds 2 internal events, eMouseRawUpdate
and eTouchRawUpdate which are never dispatched into the DOM because
PresShell::EventHandler::DispatchPrecedingPointerEvent will return false
for that and then the caller will stop handling the internal events.
There are 3 dispatchers of the internal raw update events.
One is PresShell::EnsurePrecedingPointerRawUpdate(). This dispatches the
internal event if and only if the coming event of PresShell::HandleEvent will
cause ePointerMove. The reason why PresShell::HandleEvent handles the
preceding raw-update event is, we should support ePointerRawUpdate events
for synthesized events for tests (in-process ones) and in the main process.
Additionally, if a pointerrawupdate event may destroy the target <iframe>.
In such ase, the following pointermove may need to be dispatched on its parent
window or another <iframe> window. Therefore, we need to dispatch the
internal raw update event before considering the target window (PresShell) and
handling the capturing element.
The others are BrowserChild::RecvRealMouseMoveEvent and
BrowserChild::RecvRealTouchMoveEvent. They dispatch the internal events
when they won't dispatch the received event immediately to coalesce with further
similar input.
For avoiding to dispatch the internal event for same source event, this adds
WidgetPointerHelper::convertToPointerRawUpdate member to check it in
PresShell::HandlePrecedingPointerRawUpdate.
Differential Revision: https://phabricator.services.mozilla.com/D243404
This patch tries to dispatch `ePointerRawUpdate` with
`PresShell::EventHandler::DispatchPrecedingPointerEvent` as same as usual
pointer events.
For using the path, this patch adds 2 internal events, `eMouseRawUpdate`
and `eTouchRawUpdate` which are never dispatched into the DOM because
`PresShell::EventHandler::DispatchPrecedingPointerEvent` will return `false`
for that and then the caller will stop handling the internal events.
There are 3 dispatchers of the internal raw update events.
One is `PresShell::EnsurePrecedingPointerRawUpdate()`. This dispatches the
internal event if and only if the coming event of `PresShell::HandleEvent` will
cause `ePointerMove`. The reason why `PresShell::HandleEvent` handles the
preceding raw-update event is, we should support `ePointerRawUpdate` events
for synthesized events for tests (in-process ones) and in the main process.
Additionally, if a `pointerrawupdate` event may destroy the target `<iframe>`.
In such ase, the following `pointermove` may need to be dispatched on its parent
window or another `<iframe>` window. Therefore, we need to dispatch the
internal raw update event before considering the target window (`PresShell`) and
handling the capturing element.
The others are `BrowserChild::RecvRealMouseMoveEvent` and
`BrowserChild::RecvRealTouchMoveEvent`. They dispatch the internal events
when they won't dispatch the received event immediately to coalesce with further
similar input.
For avoiding to dispatch the internal event for same source event, this adds
`WidgetPointerHelper::convertToPointerRawUpdate` member to check it in
`PresShell::HandlePrecedingPointerRawUpdate`.
Differential Revision: https://phabricator.services.mozilla.com/D243404
This patch makes the usage of `EnumTable`s safer
by using `Span`s instead of relying on an empty
element at the end.
Also the name has been changed from `EnumTable`
to `EnumTableEntry` to be more precise.
Differential Revision: https://phabricator.services.mozilla.com/D247453
This patch makes the usage of `EnumTable`s safer
by using `Span`s instead of relying on an empty
element at the end.
Also the name has been changed from `EnumTable`
to `EnumTableEntry` to be more precise.
Differential Revision: https://phabricator.services.mozilla.com/D247453
This is consistent with other browsers and with step 3 of
https://github.com/whatwg/html/issues/11155#issuecomment-2746475620
The 'urlRecord failure' subtest now behaves consistently across browsers
so the expected behavior is updated to pass when consistent.
The following tests are expecting a synchronous error event when the
delaying-the-load-event flag is reset. They do not pass in Blink. They pass
in Webkit, not because the error event is synchronous, but apparently other
factors are delaying the load event until after the error event. They usually
fail in Gecko, but are marked [FAIL, PASS] because other reasons may delay the
load event and cause intermittent PASS as reported in
https://bugzilla.mozilla.org/show_bug.cgi?id=1133483.
resource-selection-invoke-audio-constructor.html
resource-selection-invoke-set-src-not-in-document.html
resource-selection-invoke-set-src.html
Differential Revision: https://phabricator.services.mozilla.com/D242881
Gecko uses "dispatch" to mean "queue" or "fire" in different places.
This rename clarifies that the methods queue rather than fire
an event (or run a task) that has already been queued.
Differential Revision: https://phabricator.services.mozilla.com/D243050
Set the initiatorType at channel creation time so that all consumers (eg WebDriver BiDi) can
read the correct value when receiving notifications about the channel.
Differential Revision: https://phabricator.services.mozilla.com/D230538
The reason we need to switch between different state machines is that we
cannot determine the playback usage when creating the state machine.
However, if the CDMProxy is already set and is not supported by the
WMF-based CDM, we can directly use the MediaDecoderStateMachine to
avoid a later switch, which can reduce the chance of getting unnecessary
error.
Differential Revision: https://phabricator.services.mozilla.com/D227772
When the pref 'media.wmf.hevc.enabled' is not equal to `1`, the HEVC is
only enabled through the media engine, which is used for EME playback
only.
Therefore, a quick workaround to prevent websites from using HEVC on
non-EME playback is to block HEVC on HTMLMediaElement::CanPlayType() and
MediaSource::IsTypeSupported().
This workaround should be removed after enaling HEVC for all playback in
the bug 1928536.
Differential Revision: https://phabricator.services.mozilla.com/D227572
Currently, our audio wakelock is precisely synchronized with audible
sound, meaning no wakelock is held when the audio is muted or silent.
On Windows, once the sleeping timer's threshold is reached, the system
appears to enter sleep mode immediately after the audio wakelock is
released. This timing issue prevents a playlist web application from
playing the next song, as the system falls asleep right after the first
song ends.
To address this, we consider delaying the release of the audio wakelock
slightly. This adjustment would allow the next song in the playlist to
start playing and prevent the system from entering sleep mode during
extended silences, which are common at the end of songs.
Differential Revision: https://phabricator.services.mozilla.com/D218356
When a tab is backgrounded, or on some platforms, when the window is
fully covered, full decoding of a video for playback is disabled. The
video timeline still advances, but there are no valid frames for
presentation. Similarly, if an HTMLVideoElement is in the DOM tree but
marked as invisible (e.g. 'display: none;' is set), we also cease full
decoding of a video. This is the VideoDecodeMode::Suspend mode.
Chrome and Safari both continue to honour requestVideoFrameCallback when
the video element is invisible in a foreground tab. Conversely, when we
are in a backgrounded tab, Chrome suspends rVFC callbacks, while Safari
continues.
Given that we suspend requestAnimationFrame callbacks similar to Chrome
for backgrounded tabs, this patch matches our behaviour with Chrome.
The standard does not discuss the implications of visibility and
background/foreground on rVFC. We have filed an issue requesting for
clarification, and that can tracked at:
https://github.com/WICG/video-rvfc/issues/92
Differential Revision: https://phabricator.services.mozilla.com/D220274
Note this patch changes the converted enum string from X to eX in the
logs, and free the crash caused by passing `AudibleState::eMaybeAudible`
to `ToAudibilityStr`
Depends on D213363
Differential Revision: https://phabricator.services.mozilla.com/D213364
Note that this patch changes the MediaPlaybackState enum string from X
to eX (e.g., started -> eStarted), but no functional change involves.
Depends on D210117
Differential Revision: https://phabricator.services.mozilla.com/D210118
Adds ImageUsageType to ImageClient and ImageContainer to identify user of Image at WebRenderImageHost.
Some ImageContainers are used only for allocating Image. Only following types calls ImageContainer::SetCurrentImages().
- ImageUsageType::Canvas
- ImageUsageType::OffscreenCanvas
- ImageUsageType::VideoFrameContainer
Differential Revision: https://phabricator.services.mozilla.com/D211147
