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 just defines the event message, an atom for event listener attribute
and managing whether the window may have a listener.
Differential Revision: https://phabricator.services.mozilla.com/D243403
Pointer Events defines the `click`, `auxclick` and `contextmenu` target as [1]:
> 1. Let event be the click, auxclick or contextmenu event being dispatched,
> and userEvent be the user interaction event that caused the firing of event.
> 2. If userEvent is not a PointerEvent, dispatch event following the [UIEVENTS]
> spec without overriding event target and skip the remaining steps below.
> 3. If event is a contextmenu event, or userEvent was dispatched while the
> corresponding pointer was captured, then let target be the target of userEvent.
`contextmenu` case is a little bit more complicated than `click` and `auxclick`
because it's always targeted to the `pointerup` target and we don't store the
`pointerup` target and `contextmenu` is usually triggered by the native
"contextmenu" event. Therefore, this patch fixes only the case if an element
captures the pointer at dispatching `pointerup`.
However, this standardized behavior is unfortunately different from the fixed
behavior of bug 1447993. In the bug, we made the target as the element under
the pointer which may be a descendant of the capturing element. Fortunately,
even after applying this patch, the reported web app works even though the
reported page has gone and the issue of the web app is still open. For making
things safer, this patch enables the new behavior only on early beta builds and
in the nightly channel for now to get the feedback from the testers.
`test_bug1447993.html` (and `window_bug1447993.html`) keeps testing the fix of
bug 1447993 with disabling the new behavior. Instead of the test, this patch
adds new WPT to check the standardized behavior in the same steps. Chrome
files to target to the capturing element at touch, but the developers agree
with it's unexpected behavior [2].
1. https://w3c.github.io/pointerevents/#event-dispatch
2. https://github.com/w3c/pointerevents/issues/508#issuecomment-2180813312
Differential Revision: https://phabricator.services.mozilla.com/D218275
Use LayoutDevice units for most these things, since it's what they are:
ScreenIntSize(presContext->AppUnitsToDevPixels(size.width), ...
Is clearly a lie :)
Differential Revision: https://phabricator.services.mozilla.com/D228586
PreserveLayers is propagated to child frames, and it'd be nice if it
could be used just the same way it's used for the top level tab, to
avoid discarding the resources.
For the top level, if you call preserveLayers() you also need to have
renderLayers = true.
It'd be better long-term, perhaps, to have renderLayers and
preserveLayers in the parent BC. Happy to work on that refactoring if
you agree.
Testing wise, I don't think this is easily testable...
Differential Revision: https://phabricator.services.mozilla.com/D227000
When I make `ContentCacheInParent` manage the pending content command events, I forgot
to make `BrowserChild::RecvInsertText()` and `BrowserChild::RecvReplaceText()` call
`SendOnEventNeedingAckHandled()` because they have existed and I added
`BrowserChild::RecvSimpleContentCommandEvent()`. Therefore, this patch makes them call
`SendOnEventNeedingAckHandled()`.
Additionally, `ContentCacheInParent::OnEventNeedingAckHandled()` returns without
managing the count if it's called for the content command events. Therefore, this patch
fixes the early return bug too.
Differential Revision: https://phabricator.services.mozilla.com/D225749
This is all super-hacky (see a lot of the XXXcjones comments).
Simplify it... We never create widgets with a bare native parent but no
nsIWidget parent. Pass nsIWidgets and deal with things correctly.
There were also things that were dealing with stuff that can't happen,
like top level popups, children of PuppetWidgets, or such.
Instead of overriding Create(), let's just teach nsBaseWidget about
non-native (headless/puppet) widgets.
Remove lots of old APIs for the native window stuff that are unused
and/or unimplemented.
Differential Revision: https://phabricator.services.mozilla.com/D224613
The canceledReason is added to the RequestData used to build the
RemoteWebProgressRequest. This canceledReason is useful for consumers such
as WebDriverBiDi which need to emit different error messages depending on
the reason why a specific navigation request was canceled.
Differential Revision: https://phabricator.services.mozilla.com/D223174
Currently, `EventStateManager` handles some content commands only in the parent
process. Therefore, if `eSetSelection` event or something is being handled in
the focused remote process, the command may be disabled yet.
Avoiding the race conditions, we should handle the content command events in the
focused process.
Differential Revision: https://phabricator.services.mozilla.com/D222789
Currently, `EventStateManager` handles some content commands only in the parent
process. Therefore, if `eSetSelection` event or something is being handled in
the focused remote process, the command may be disabled yet.
Avoiding the race conditions, we should handle the content command events in the
focused process.
Differential Revision: https://phabricator.services.mozilla.com/D222789
The BrowserChild should only be cleared on EndDragSession, which is sent when
the user finishes or cancels dragging. This is reciprocal to it being set in
StartDragSession.
The change to nsDragSessionProxy::EndDragSessionImpl is non-functional -- it
highlights the BrowserChild symmetry above.
Differential Revision: https://phabricator.services.mozilla.com/D222389
Sends OOP drop events to content analysis for approval before sending them to
the DOM. It intercepts drop events at the browser level and sends them to CA
before calling stopPropagation and preventDefault on them. (CA also presents a
modal dialog over the tab.) The drag session then ends as usual in the parent
process but remains open on the related browser in the process where it would be
sent to the DOM while the drop is being analyzed. While CA runs, the browser
dispatches an eQueryDropTargetHittest event to locate the drop target while the
event screen coordinates are still valid. When CA is complete, a drop or
dragexit event is sent to the drop target (drop if it was approved by CA). Calls
to EndDragSession are delayed during this.
Differential Revision: https://phabricator.services.mozilla.com/D219201
This comment assumes dom.events.datatransfer.protected.enabled=false. when
dom.events.datatransfer.protected.enabled=true (which matches the spec and is
not the default), the behavior is fine as-is.
Since bug 1871222 (by one perspective) moved drag sessions from PContents to
PBrowsers, we need to update permission handling for in-process "remote"
sessions (ones that started on one PBrowser and currently target another). When
the target and source are in the same process, they don't properly handle
privileged DataTransfer access. We are currently denying privileged access to
some in-process principals because we incorrectly use the system principal. The
system principal always happens to give the right result for out-of-process
remote sessions, which were the only kind that existed before bug 1871222.
This solution creates the "remote" DataTransfer with the "correct" (not system)
principal of its source content. However, this misses the case where two
different browsers are at the same location (same principal) -- each would
incorrectly get privileged access to the other's DataTransfer in a drag. We
avoid that case by limiting the change to extension processes. This means that
remote DataTransfers created in the extension process will check for protected
access using a principal check against the drag-source-element's principal but,
otherwise, DataTransfers will continue to use the system principal for the
check.
Differential Revision: https://phabricator.services.mozilla.com/D219074
When using autocorrect, we should use `insertReplacementText` according
to https://github.com/w3c/input-events/issues/152. So I would like to
add eContentCommandReplaceText command for this.
Also, this command has an option that is source string text. When
processing text subsitution, parent process doesn't know whether
target replaced text is modified. So I add this option for check.
Differential Revision: https://phabricator.services.mozilla.com/D213511
Split the class inheritance trees for nsIDragService and nsIDragSession.
Remember that, before the start of this patch series, the inheritance
diagram was:
nsDragService -> nsBaseDragService -> nsIDragService + nsIDragSession
and the only instance was a singleton. We switched it to:
nsDragService -> nsDragSession -> nsBaseDragService -> nsIDragService + nsBaseDragSession -> nsIDragSession
and maintained the singleton. This allowed us to allow us to move things to
the new classes without breaking behavior. We are done with that,
so we can now change the inheritance to its final form:
nsDragService -> nsBaseDragService -> nsIDragService
nsDragSession -> nsBaseDragSession -> nsIDragSession
Of course, we also need to properly construct and release the
nsIDragSessions (formerly part of the singleton), so that is done here as
well. That happens in nsBaseDrag[Service|Session] for parent process drags
and in nsDrag[Service|Session]Proxy for content. This is all fairly
straightforward, except in the case of gtk, where we need to change
some callback behavior.
Differential Revision: https://phabricator.services.mozilla.com/D211084
This is a straightforward move. It does take the liberty of breaking out an
EndDragSessionImpl method, which will be needed later.
Differential Revision: https://phabricator.services.mozilla.com/D211083
nsBaseDragService keeps track of the processes that might need to cancel a drag with EndDragSession and this is technically correct since the drag session is a singleton in the child process, but this series of patches changes those sessions to be per-PuppetWidget/BrowserChild. This allows content processes to distinguish which of its browsers is engaged in a drag.
Differential Revision: https://phabricator.services.mozilla.com/D211062
Updates each client of the nsContentUtils method to get the right drag session -- the one for the widget that is currently the source or target of the drag session.
The change to nsDOMWindowUtils::DispatchDOMEventViaPresShellForTesting() supports the change to WidgetDragEvent::InitDropEffectForTests() and enabled a
large number of test fixes in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D211067
`eContextMenu` event may be fired from `widget`. Therefore, different from
`ePointerClick` and `ePointerAuxClick`, they may cross the process boundary,
may be handled by APZ and may be dispatched into the DOM after a delay.
Therefore, this patch is complicated than the previous patch. This adds
* New IPC message handlers for sending/receiving a `WidgetPointerEvent`
* New `DelayedPointerEvent` class and templated `MouseInput::ToWidgetEvent`
* `PresShell::EventHandler` handles `eContextMenu` as same as `WidgetMouseEvent`
Differential Revision: https://phabricator.services.mozilla.com/D213003
The builtin legacy IME of Windows to type a Unicode with typing a code point
causes consumed `eKeyDown` events while typing the code point, i.e., without
`eKeyPress` (FYI: The consumed state is not exposed to the web, it's used only
in chrome UI for the compatibility with Chrome). Then, `BrowserChild` store
whether the last `eKeyDown` was consumed or not to prevent the following
`eKeyPress`. Finally, a `eKeyPress` event is fired to input the Unicode
character after `eKeyUp` for `Alt`. The stored value is set to new value only
when another `eKeyDown` event is sent from the parent process. Therefore,
the last digit inputting `eKeyDown` causes `BrowserChild` thinking the last
`eKeyDown` is consumed so that the last `eKeyPress` is not dispatched.
This patch makes `BrowserChild` to store the `code` value of the last consumed
`eKeyDown` and check the `code` value to consider whether coming `eKeyPress`
should be or not be dispatched to `PresShell` and the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D207957
The builtin legacy IME of Windows to type a Unicode with typing a code point
causes consumed `eKeyDown` events while typing the code point, i.e., without
`eKeyPress` (FYI: The consumed state is not exposed to the web, it's used only
in chrome UI for the compatibility with Chrome). Then, `BrowserChild` store
whether the last `eKeyDown` was consumed or not to prevent the following
`eKeyPress`. Finally, a `eKeyPress` event is fired to input the Unicode
character after `eKeyUp` for `Alt`. The stored value is set to new value only
when another `eKeyDown` event is sent from the parent process. Therefore,
the last digit inputting `eKeyDown` causes `BrowserChild` thinking the last
`eKeyDown` is consumed so that the last `eKeyPress` is not dispatched.
This patch makes `BrowserChild` to store the `code` value of the last consumed
`eKeyDown` and check the `code` value to consider whether coming `eKeyPress`
should be or not be dispatched to `PresShell` and the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D207957
