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
When GtkWidget is hidden, underlying wl_surface is deleted. We need to also update EGLSurface of GtkWidget (GtkCompositorWidget)
as EGLSurface is directly linked to wl_surface:
- When GtkWidget is hidden, call GtkCompositorWidget::DisableRendering(). That releases GtkCompositorWidget resources
related to GtkWidget (XWindow/XVisual etc.) and marks the widget as hidden.
- If GtkWidget is backed by EGL call compositor resume which forces compositor to create new EGLSurface.
- Make sure GLContextEGL can create EGLSurface even when GtkWidget is hidden and wl_surface is missing.
It prevents fallback to SW rendering or pause RenderCompositorEGL which leads to Bug 1777664 (whole browser UI freeze).
- Return early from RenderCompositorEGL::BeginFrame()/RenderCompositorEGL::EndFrame() when GtkCompositorWidget is hidden.
Depends on D157357
Differential Revision: https://phabricator.services.mozilla.com/D157358
Map/Unmap signals creates and deletes mContainer wayland surface and EGL window.
As we need to call the handlers in correct order (mContainer::map -> nsWindow::map and nsWindow::unmap -> mContainer::unmap)
connect the signals to mContainer widget and call mContainer::unmap from nsWindow::unmap.
Then nsWindow::unmap can update compositor before wl_surface/EGL window is released by mContainer.
Differential Revision: https://phabricator.services.mozilla.com/D157357
When GtkWidget is hidden, underlying wl_surface is deleted. We need to also update EGLSurface of GtkWidget (GtkCompositorWidget)
as EGLSurface is directly linked to wl_surface:
- When GtkWidget is hidden, call GtkCompositorWidget::DisableRendering(). That releases GtkCompositorWidget resources
related to GtkWidget (XWindow/XVisual etc.) and marks the widget as hidden.
- If GtkWidget is backed by EGL call compositor resume which forces compositor to create new EGLSurface.
- Make sure GLContextEGL can create EGLSurface even when GtkWidget is hidden and wl_surface is missing.
It prevents fallback to SW rendering or pause RenderCompositorEGL which leads to Bug 1777664 (whole browser UI freeze).
- Return early from RenderCompositorEGL::BeginFrame()/RenderCompositorEGL::EndFrame() when GtkCompositorWidget is hidden.
Depends on D157357
Differential Revision: https://phabricator.services.mozilla.com/D157358
Map/Unmap signals creates and deletes mContainer wayland surface and EGL window.
As we need to call the handlers in correct order (mContainer::map -> nsWindow::map and nsWindow::unmap -> mContainer::unmap)
connect the signals to mContainer widget and call mContainer::unmap from nsWindow::unmap.
Then nsWindow::unmap can update compositor before wl_surface/EGL window is released by mContainer.
Differential Revision: https://phabricator.services.mozilla.com/D157357
When widget is hidden gtk_window_move() does not move the widget but sets new widget coordinates
when widget is mapped again.
If popup used move-to-rect before (GdkWindow has POSITION_METHOD_MOVE_TO_RECT set),
popup will use move-to-rect again when it's mapped and we'll get bogus move-to-rect callback.
In this patch we implement nsWindow::WaylandPopupMovePlain() to perform simple popup movement.
It calls gdk_window_move() to set position_method to POSITION_METHOD_MOVE_RESIZE when popup is hidden
so we'll use simple move when popup is shown and don't slip to move-to-rect.
Depends on D156821
Differential Revision: https://phabricator.services.mozilla.com/D157432
If popup is moved we can't use recent popup position (mBounds) to check popup placement but
use requested position given at nsWindow::NativeMoveResize().
Differential Revision: https://phabricator.services.mozilla.com/D156821
If there's a gap between popups we can't use move-to-rect as anchor needs to be placed inside of parent popup.
In such case place anchor to upper corner of parent popup and submit popup position as offset.
Differential Revision: https://phabricator.services.mozilla.com/D156820
Right now we look for first parent only at nsWindow::WaylandGetParentPosition() and that's wrong.
WaylandGetParentPosition() is expected to return popup position in root coordinates regardless of popup parent nembers.
In this patch we calc popup position according to whole popup chain.
Differential Revision: https://phabricator.services.mozilla.com/D156673
When we open a popup window (tooltip for instance) on top of GDK_WINDOW_TYPE_HINT_UTILITY popup, Mutter compositor sends bogus
leave/enter events to the GDK_WINDOW_TYPE_HINT_UTILITY popup (https://gitlab.gnome.org/GNOME/gtk/-/issues/5089).
That leads to immediate tooltip close. As a workaround ignore these
bogus events.
We need to check two affected window types:
- toplevel window with at least two child popups where the first one is
GDK_WINDOW_TYPE_HINT_UTILITY.
- popup GDK_WINDOW_TYPE_HINT_UTILITY with a child popup.
We ignore two bogus leave/enter sequences which are fired by mutter together:
1. Leave (popup) -> Enter (toplevel)
2. Leave (toplevel) -> Enter (popup)
Differential Revision: https://phabricator.services.mozilla.com/D156301
We don't need to hide/show GDK_WINDOW_TYPE_HINT_UTILITY popup type to change it's position.
Hide it only if we need to set correct popup type as such change is done in map event.
Differential Revision: https://phabricator.services.mozilla.com/D156305
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Remove outdated check for move-to-rect. It's redundant and it's implemented in more complex way by nsWindow::WaylandPopupCheckAndGetAnchor() now.
Differential Revision: https://phabricator.services.mozilla.com/D154882
