A popup attached to a modal parent window doesn't get mouse events
from Gtk as they'are directed to the modal parent. This is usually solved
by pointer grab which that doesn't work on Wayland in our current
setup as it performs show and grab in one step.
We emulate it by setting popup as modal too but then patent
window doesn't get mouse events outside of popup (Bug 1899299).
we need to listen
Surprisingly attaching events handler to mShell fixes it
and we're getting events from both parent and popup windows.
Differential Revision: https://phabricator.services.mozilla.com/D221290
The original Chromium listener code has a few infelicities in its API.
* The current session ID is always available, so the `Nothing()` branch
is impossible. Remove the `Maybe` from the interface.
* If session-change messages for other sessions are received, discard
them early rather than propagating them.
* Use the whole DWORD value supplied by `GUID_SESSION_DISPLAY_STATUS`,
rather than just the first byte. (This has no effect here, since
`MONITOR_DISPLAY_STATE` is an enum with very few values, but might if
someone blindly copies this code with minimal adjustments to be used
with another `PBT_POWERSETTINGCHANGE` value.)
Differential Revision: https://phabricator.services.mozilla.com/D220749
`WinEventHub` was largely taken from Chromium, where its dynamic
connection/disconnection features are presumably more used. We don't
have any need for that, and anyway if we ever do it'll be easy to add
it alongside the static functionality or even migrate the latter over.
Hardwire the relevant message-processing and invocation directly into
the hidden window's WNDPROC, rather than providing a registration
system. Following the discoveries made in bug 1571516, also remove the
additional failure-mode checks added in bug 1852801, reverting to a
crash (which can be unified with 1571516 when it shows up).
This has, as fallout, a minor functional change to the occlusion
tracker: the subfeature prefs mentioned above are now checked at
message-receipt time, rather than at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D220639
This fixes four issues:
1. The test didn't provide enough movement to generate a drag session on the
source before moving to the target. This meant that, when they were in
different windows, Gecko wouldn't send dragleave to the source or dragenter
to the target. It also never sent dragenter to the source in the first
place. This remedies that.
2. dragenter and dragleave weren't properly handled because the test was sending
dragleaves instead of dragexits (the latter being what Gecko expects and the
former being synthesized from that -- see e.g. nsNativeDragTarget::DragLeave).
This now uses dragexits and sets the proper expectations.
3. expectProtectedDataTransferAccess was needlessly complicated and, after #1,
gave the wrong answers for some events like dragenter called on the source.
4. The event handler wasn't checking for exceptions and the drop handler was
intentionally causing one, which was causing it to miss the rest of its
execution.
Differential Revision: https://phabricator.services.mozilla.com/D219550
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
In bug 1906034, I attempted to preserve the workaround for the white line issue from bug 1700211, but it did not prevent the white line from appearing. Hiding the separator in response to full-screen events avoids the issue.
Differential Revision: https://phabricator.services.mozilla.com/D221576
The sense of the test-condition here was reversed: as the preference's
name states, this should run when the preference is false (as it is by
default).
Differential Revision: https://phabricator.services.mozilla.com/D221234
- This patch separates RFPTarget::PointerEvents into PointerEvents and PointerId.
- PointerId protection is disabled for Android.
- WidgetEvents emit non-primary mouse events on Android because any touch other than 1nd touch is considered non-primary
- Sets maximum touch points to 5 on Android
Differential Revision: https://phabricator.services.mozilla.com/D221241
When `HTMLEditor` handles the design mode, `IMEContentObserver` observes the
`<body>` if there is. However, web apps may remove it. Then, we need to
recreate `IMEContentObserver` with emulating a focus move because it's difficult
to compute the difference between the old root and the new root (IME focus
notification sends all content to the parent, it's faster in most cases in this
situation). This was fixed in bug 1911010. However, there are remaining issues
after that.
When new `<body>` or the original `<body>` is connected again,
`IMEContentObserver` does not restart to observe the new `<body>`. So,
`IMEContentObserver` working differently after the `<body>` is even temporarily
removed. This make it harder to reproduce reported bugs.
Additionally, if the document element is removed, `IMEContentObserver` won't
be recreated until the document gets focus again even after new root and/or
`<body>` element is connected. This makes IME users inconvenient with such
tricky editors.
This patch makes `HTMLEditor::NotifyRootChanged` notifies `IMEStateManager`
of the editor root element change. Then, the new method of `IMEStateManager`
updates IME enabled state and recreate `IMEContentObserver` with emulating
a focus move.
Differential Revision: https://phabricator.services.mozilla.com/D220362
We didn't have any ideas of crossing mouse/pointer events which finally cause
synthesized move event to dispatch corresponding boundary events. However,
`mSynthesizeMoveAfterDispatch` of `eMouseUp` is set to `true` in most cases
because the preceding `ePointerUp` causes releasing implicit capture and
`eMouseUp` may be handled in `EventStateManager::HandleCrossProcessEvent` if
there is a remote target underneath the pointer after `ePointerUp` is handled.
Therefore, we should allow such `eMouseUp` events to cross the process
boundary, but we don't need to copy the members (See the comment in
`ParamTraits<mozilla::WidgetMouseEvent>` for the reason).
I have no idea how to write the xorigin test within WPT. Therefore, this patch
does not contain new test.
Differential Revision: https://phabricator.services.mozilla.com/D220773
This patch moves the call to BaseWindow::Destroy() and ::OnDestroy() to
the end of nsCocoaWindow::Destroy(). It adds a death grip on this before
remove this from mParent. This should keep the window in a more stable
state throughout the function scope.
Differential Revision: https://phabricator.services.mozilla.com/D216066
If there aren't any browser windows, we're either very early in startup
or shutting down. In these cases, it's probably fine to not know if
tablet mode is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D219945
`mozAutoDocUpdate` does not make it in a document change when container node
of `insertBefore` has already been removed from the tree. Therefore, once
`IMEContentObserver::mRootElement` is removed from the DOM tree without a
focus move, `IMEContentObserver` is notified mutations not in a document change.
Similar situations are handled in `IMEStateManager::OnRemoveContent` with
emulating a focus change and that will destroy the active `IMEContentObserver`.
Therefore, if `IMEContentObserver::mRootElement` is removed, we should emulate
a focus move when `IMEStateManager` does not have focused element but there
is active `IMEContentObserver` (that means it is/was in the design mode).
However, checking whether the removed node contains the observing node of the
active `IMEContentObserver` may be expensive. So, doing expensive things in
`IMEStateManager::OnRemoveContent` may make mutations slower. Therefore, this
patch makes `IMEContentObserver` observe `ParentChainChanged` and it let
`IMEStateManager` know that with calling its
`OnParentChainChangedOfObservingElement`. Finally, it calls
`IMEStateManager::OnRemoveContent` to emulate "blur" (and refocus if it's
required).
Differential Revision: https://phabricator.services.mozilla.com/D218696
No regressions have been reported reported since Bug 1882001, then it seems OK to re-enable zero copy video of hardware decoded video with NVIDIA GPUs to release.
Differential Revision: https://phabricator.services.mozilla.com/D219838
`mozAutoDocUpdate` does not make it in a document change when container node
of `insertBefore` has already been removed from the tree. Therefore, once
`IMEContentObserver::mRootElement` is removed from the DOM tree without a
focus move, `IMEContentObserver` is notified mutations not in a document change.
Similar situations are handled in `IMEStateManager::OnRemoveContent` with
emulating a focus change and that will destroy the active `IMEContentObserver`.
Therefore, if `IMEContentObserver::mRootElement` is removed, we should emulate
a focus move when `IMEStateManager` does not have focused element but there
is active `IMEContentObserver` (that means it is/was in the design mode).
However, checking whether the removed node contains the observing node of the
active `IMEContentObserver` may be expensive. So, doing expensive things in
`IMEStateManager::OnRemoveContent` may make mutations slower. Therefore, this
patch makes `IMEContentObserver` observe `ParentChainChanged` and it let
`IMEStateManager` know that with calling its
`OnParentChainChangedOfObservingElement`. Finally, it calls
`IMEStateManager::OnRemoveContent` to emulate "blur" (and refocus if it's
required).
Differential Revision: https://phabricator.services.mozilla.com/D218696
This is a temporary measure. We would like to destroy the native window
here, but we want to see the effect of removal on crash volume.
This patch also moves the call to BaseWindow::OnDestroy() to the end of
::Destroy(). This is necessary to get tests to pass. It may also be the
real fix for this Bug.
Differential Revision: https://phabricator.services.mozilla.com/D216066
macOS offers an enum, NSTrackingInVisibleRect, which keeps the tracking
area up-to-date with the visible area of the window. This patch adds
this enum to our tracking area at window creation time, and removes the
code that was recreating the tracking area with every window resize.
It also moves the responsibility of creating and removing the tracking
area to the nsCocoaWindow, which keeps us from manipulating the tracking
area during deallocation.
Differential Revision: https://phabricator.services.mozilla.com/D219098
They do it only when given event class is expected one but they don't include
`ePointerEventClass` which is newly used for `eContextMenu` event since
bug 1675847.
Differential Revision: https://phabricator.services.mozilla.com/D219632
Making ENSURE_SUCCESS return the result of StealNSResult() ensures that
exceptions in the ErrorResult are deal with. We can then signal that through
WouldReportJSException.
Differential Revision: https://phabricator.services.mozilla.com/D214792
Martin Stransky
Butkovits Atila
Ray Kraesig
David Parks
Greg Stoll
Sam Johnson
Fatih
Emilio Cobos Álvarez
Masayuki Nakano
delthas
Brad Werth
Olli Pettay
Makoto Kato
Kagami Sascha Rosylight
Gregory Pappas
Norisz Fay
Florian Quèze
Stanca Serban
sotaro
Timothy Nikkel
Iulian Moraru
Peter Van der Beken