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
If a HWND whose messages are logged is not destroyed before application
shutdown, any static data in NativeEventLogger's persistent store will
not be cleared out. This can show up as a memory leak during testing.
Set up a RunOnShutdown hook to ensure that everything is actually
destroyed during shutdown, even if some other module is ill-behaved.
Differential Revision: https://phabricator.services.mozilla.com/D222382
This was caught by Markus. When you hover over an overlay scrollbar on
macOS, you'd hit this the PaintScrollbar() code-path (or rather, you
won't bail out from the if (overlay && !hovered)), but macOS draws the
track in PaintScrollbarTrack().
Android doesn't hit this because android scrollbars can't ever be
hovered (they have pointer-events: none). This is a better fix than
D222172, which didn't paint the background for the non-overlay
scrollbars...
This doesn't change behavior since scrollbar and the track have the same
size (as cocoa scrollbars can never have buttons). Removing
nsSliderFrame is a refactor for another day if ever.
Differential Revision: https://phabricator.services.mozilla.com/D222194
That's what we use for painting in all platforms except macOS with
overlay scrollbars, where we make it sticky. Make the stickiness more
explicit (this also fixes the sticky state getting cleaned up too
early).
Differential Revision: https://phabricator.services.mozilla.com/D222161
getURIForDropEvent delegates to getURIForBrowsingContext -- the ground truth for
CA URIs.
This also adds a check that getURIForDropEvent is correctly called in CA tests.
We do not yet test that it returns the right value -- that is future work.
Differential Revision: https://phabricator.services.mozilla.com/D222192
We had the same list of attributes in multiple places, put it in
Theme.cpp.
Only a few states can change widget state. Just hardcode them in
RestyleManager.cpp (where there was already some of it) instead of
reusing a weird API.
Shouldn't have any behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D222160
We had the same list of attributes in multiple places, put it in
Theme.cpp.
Only a few states can change widget state. Just hardcode them in
RestyleManager.cpp (where there was already some of it) instead of
reusing a weird API.
Shouldn't have any behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D222160
This was caught by Markus. When you hover over an overlay scrollbar,
you'd hit this the PaintScrollbar() code-path (or rather, you won't bail
out from the if (overlay && !hovered)), but macOS draws the track in
PaintScrollbarTrack().
Android doesn't hit this because android scrollbars can't ever be
hovered (they have pointer-events: none).
Differential Revision: https://phabricator.services.mozilla.com/D222172
On macOS 11, MOZTitlebarAccessoryView's viewWillMoveToWindow: is called both when transitioning to full screen, and when transitioning out of full screen. In the case of transitioning into full screen, the window passed to viewWillMoveToWindow: has titlebarAppearsTransparent=false, meaning that the condition added to this function in bug 1906034 caused the title bar separator to always be enabled when in full screen on macOS 11. This patch fixes the logic to instead check if the passed NSWindow is our ToolbarWindow or something else.
On later macOS releases, MOZTitlebarAccessoryView's viewWillMoveToWindow: is called when transitioning out of from full screen, but not when transitioning to full screen. This is why disabling the title bar separator in windowDidEnterFullScreen: is also necessary.
Differential Revision: https://phabricator.services.mozilla.com/D221909
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