The main issue is the confusion between mGdkWindow and the toplevel when
we draw with client decorations. Though something else broke since we
enabled them and now even with MOZ_GTK_TITLEBAR_DECORATION=system the
bug reproduces.
The thing that's supposed to hide the tooltip on nsXULTooltipListener is
the mouseout event handler, but without this fix we would upgrade the
eMouseExitFromWidget to a synthesized mouse move here:
https://searchfox.org/mozilla-central/rev/2fc2ccf960c2f7c419262ac7215715c5235948db/dom/events/EventStateManager.cpp#721-732
Make leave-notify handling properly parallel to enter-notify in order to
properly notify gecko of the mouse leaving the window, thus fixing the
bug.
We also need to stop doing pointer grabs. Reasoning:
* We already don't do it on Wayland (see bug 1377084).
* The APIs we use are deprecated.
* The pointer grabs send spurious top-level leave/enter-notify pairs
which aren't detectable (the leave/enter event pair sent to the
toplevel window doesn't have the GDK_POINTER_{GRAB,UNGRAB} reasons).
* The code we had to avoid them (bug 369599) no longer works with CSD:
* The window gets hit even though it's behind other windows.
* The hit-test still returns true when hitting the window decorations.
So we're effectively eating virtually all useful leave-notify events,
which is obviously not great. Also gtk4 apps don't seem to have the same
pointer-grabbing on context menus etc.
Differential Revision: https://phabricator.services.mozilla.com/D163646
We need to return correct EGLWindow from moz_container_wayland_get_egl_window() with correct scale/size
and also keep the EGLWindow up to date. In this patch we do:
- Implement moz_container_wayland_egl_window_needs_size_update() and use it in nsWindow::SetEGLNativeWindowSize().
Avoid redundant moz_container_wayland_egl_window_set_size()/moz_container_wayland_set_scale_factor() calls as it may lead to resize callback calls to MESA.
- If wl_container::eglwindow is present, check its size/scale in moz_container_wayland_get_egl_window() and update size/scale if needed.
- Use nsIntSize single param instead of width/height pairs in some moz_container_* functions.
- Assert when gtk_widget_get_window(container) returns null.
Differential Revision: https://phabricator.services.mozilla.com/D163698
The main issue is the confusion between mGdkWindow and the toplevel when
we draw with client decorations. Though something else broke since we
enabled them and now even with MOZ_GTK_TITLEBAR_DECORATION=system the
bug reproduces.
The thing that's supposed to hide the tooltip on nsXULTooltipListener is
the mouseout event handler, but without this fix we would upgrade the
eMouseExitFromWidget to a synthesized mouse move here:
https://searchfox.org/mozilla-central/rev/2fc2ccf960c2f7c419262ac7215715c5235948db/dom/events/EventStateManager.cpp#721-732
Make leave-notify handling properly parallel to enter-notify in order to
properly notify gecko of the mouse leaving the window, thus fixing the
bug.
Differential Revision: https://phabricator.services.mozilla.com/D163646
We can delete nsWindow but reference to it is kept by GtkCompositorWidget and nsWindow destructor may be called from Compositor thread where GtkCompositorWidget may be deleted.
Allow such scenario if nsWindow is already an empty shell and only nsWindow memory is released from Compositor thread.
Differential Revision: https://phabricator.services.mozilla.com/D163145
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
Updating mBounds.Size() without calling WindowResized leaves the window
temporarily in a state where inner and outer sizes are out of sync.
BrowserParent::UpdatePosition should call BrowserParent::UpdateDimension
with the size during the last update, rather than the current window
size. There is an edge case where a call can happen between a resize and
its reflow, and a second resize could prevent the reflow from changing
the frame loader size, leaving the BrowserChild with an outdated outer
size.
Differential Revision: https://phabricator.services.mozilla.com/D158343
The first size-allocate is likely (or guaranteed) to be of the size at
the time of the first NativeShow(true) call. Any resize between show and
the first size-allocate will be accounted for in a second size-allocate
signal. If we update and dispatch the window size at the beginning of
such a resize, we end up reverting back to previous size from the first
size-allocate signal before dispatching the size for the resize again
from the second size-allocate signal.
Differential Revision: https://phabricator.services.mozilla.com/D158580
Due to https://gitlab.gnome.org/GNOME/gtk/-/issues/4437 / Bug 1710344 we need to add popup window position to D&D coordinates provided by Gtk.
In this patch always use GdkWindow derived from mShell which is attached to parent window.
Don't use GdkWindow of mContainer which is nested child window and it's positioned at 0,0.
Differential Revision: https://phabricator.services.mozilla.com/D158653
The rounding error workaround is broken - on recent Gtk it produces needless stream of move-to-rect callback.
It's because we move popup of GDK_WINDOW_TYPE_HINT_POPUP_MENU type and this is positioned by Gtk by move-to-rect even if gtk_window_move() is called.
But it looks like we don't need this workaround any more due to recent fixes (1786525, 1786588, 1786525, 1765714).
Differential Revision: https://phabricator.services.mozilla.com/D158217
We can't use move-to-rect if there are more parents of wl_subsurface popups types.
It's because wl_subsurface is ignored by xgd_popup (created by move-to-rect) so our popup scenario:
toplevel -> xgd_popup(1) -> wl_subsurface(2) -> xgd_popup(3)
looks for Wayland compositor as:
toplevel -> xgd_popup(1) -> xgd_popup(3)
If xgd_popup(1) and xgd_popup(3) are not adjacent then move-to-rect applied to xgd_popup(3) fails and we get missing popup.
Depends on D158120
Differential Revision: https://phabricator.services.mozilla.com/D158121
Wne context menu is positioned by plain move, we need relative popup coordinates. So calculate them according to context menu parent popup.
Differential Revision: https://phabricator.services.mozilla.com/D158120
move-to-rect offset does not work realibly in mutter and can lead to invisible window.
It's used mainly for tooltips so let's skip it for now.
Differential Revision: https://phabricator.services.mozilla.com/D157926
