When GDK_BACKEND is wayland, widget is not fully mapped during creating CompositorSession. Needs to create valid EGLSurface after widget is fully mapped.
Differential Revision: https://phabricator.services.mozilla.com/D18940
Recently we quit nsWindow::OnWindowStateEvent()/window_state_event handler when titlebar needs an update due to focus change.
That's incorrect as we need to process other information from the handler - maxminized/normal window state.
Differential Revision: https://phabricator.services.mozilla.com/D18681
--HG--
extra : moz-landing-system : lando
When hardware acceleration is enabled, GLContextGLX::FindVisual() is used to choose visual. When widget does not request AlphaVisual, the FindVisual() always choose RGB(24bit) visual. It causes to loose alpha during readback.
Differential Revision: https://phabricator.services.mozilla.com/D18179
--HG--
extra : moz-landing-system : lando
This cleans up a bit and allows us to be smarter about which cursors
should we allow from content or what not, which will help with bug 1445844 and
co.
Differential Revision: https://phabricator.services.mozilla.com/D16711
To support rounded corners of Gtk+ titlebar themes (Adwaita, Radiance..) in GNOME we need to use X shape mask
as fully transparent toplevel window causes various issues (like Bug 1516224).
We draw mShell as transparent and mContainer as non-transparent with shape mask applied. The shape mask
is generated only when titlebar rendering is enabled and it's generated from GtkHeaderBar Widget
to match the exact look.
We use existing mTransparencyBitmap for the shape mask where mTransparencyBitmapForTitlebar controls
whether it's a general shape mask or our specialised shape for titlebar only.
This is already enabled for GNOME environment by default. So there's a new preference
widget.default-hidden-titlebar added to easily disable it if any issue appears
during testing.
Differential Revision: https://phabricator.services.mozilla.com/D17283
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
Move all implementation of nsWindow::OnKeyPress() and nsWindow::OnKeyRelease()
into KeymapWrapper because the implementation is a little bit complicated
but not loggable. When we get bug reports which depend on environment around
IME/key handling like bug 1498823, it's useful to log those methods behavior
too.
Differential Revision: https://phabricator.services.mozilla.com/D15323
--HG--
extra : moz-landing-system : lando
- Wayland - Set proper scale to wl_egl_window when it's created and resized
- Wayland - Remove unused gtk_widget_set_app_paintable()
Differential Revision: https://phabricator.services.mozilla.com/D13725
--HG--
extra : moz-landing-system : lando
Use frame callback to determine if we can draw to wl_surface owned by GtkWidget and use it as a base for EGL Window.
Differential Revision: https://phabricator.services.mozilla.com/D13722
--HG--
extra : moz-landing-system : lando
Titlebar (StyleAppearance::MozWindowTitlebar) style depends on toplevel window focus
and we need to redraw it when toplevel window focus changes.
Unfortunately according to https://gitlab.gnome.org/GNOME/gtk/issues/1395
the toplevel window focus can't be used here as we can have active but unfocused
toplevel window during drag & drop.
Gtk+ controls window active appearance by window-state-event signal
but gecko uses focus-in/out signals, so we need to repaint the titlebar
when window-state-event comes *after* focus-in/out signals.
We can't call mWidgetListener->WindowActivated() (and WindowDeactivated())
as it was already called from focus-in/out handlers before window-state-event.
Depends on D13051
Differential Revision: https://phabricator.services.mozilla.com/D13052
--HG--
extra : moz-landing-system : lando
This is a workaround for https://gitlab.gnome.org/GNOME/gtk/issues/1395
Gtk+ controls window active appearance by window-state-event signal
but gecko uses focus-in/out signals.
So we need to set the the titlebar state
when window-state-event comes *after* focus-in/out signals.
Differential Revision: https://phabricator.services.mozilla.com/D13051
--HG--
extra : moz-landing-system : lando
- Don't create wl_subsurface in map event but rather when it's requested by compositor.
- Don't create wl_surface at nsWindow::OnExposeEvent but check ready_to_draw instead.
- Rename parent_surface_committed_handler to frame_clock_after_paint_handler.
- Rename parent_surface_committed to ready_to_draw.
- Rename needs_clear to surface_needs_clear.
Depends on D13404
Differential Revision: https://phabricator.services.mozilla.com/D13405
--HG--
extra : moz-landing-system : lando
Currently, IMContextWrapper::OnKeyEvent() assumes that IME won't synthesize
keyboard event asynchronously again in some cases. For example, one of the
cases is that user inputs text with a dead key sequence. However, IME may
synthesize key event asynchronously only in a few cases even in a dead key
sequence. Unfortunately, for not losing a chance to dispatch eKeyDown/eKeyUp
event, we need to keep dispatching eKeyDown or eKeyUp event when we receive
original event in dead key sequence. However, according to this bug, we need to
stop dispatching eKeyDown and eKeyUp events when we receive unexpected
async synthesized key event.
If IMContextWrapper::OnKeyEvent() needs to return whether it (has already)
dispatched an eKeyDown or eKeyUp and whether it was consumed, then,
nsWindow can stop dispatching redundant eKeyDown and eKeyUp events.
So, this patch makes IMContextWrapper::OnKeyEvent() return
KeyHandlingState enum class instead of just a bool value to notify the caller
of detail of the event status. And also makes each caller of nsWindow not
dispatch eKeyDown nor eKeyUp event when it returns
KeyHandlingState::eNotHandledButDispatched or
KeyHandlingState::eNotHandledButConsumed.
Differential Revision: https://phabricator.services.mozilla.com/D12517
--HG--
extra : moz-landing-system : lando
We've added nsIWidget::GetDesktopToDeviceScaleByScreen which will return scale factor of the newly placed window
according to its position on the display. This change is to move implementation to the nsIWidget derived classes.
We need that for GTK Wayland, because on the Wayland we cannot determine absolute position of the window, we
need to use parent's window scale factor. For other platforms the GetDesktopToDeviceScaleByScreen is implemented
in nsBaseWidget.
Differential Revision: https://phabricator.services.mozilla.com/D7290
--HG--
extra : moz-landing-system : lando
We've added nsIWidget::GetDesktopToDeviceScaleByScreen which will return scale factor of the newly placed window
according to its position on the display. This change is to move implementation to the nsIWidget derived classes.
We need that for GTK Wayland, because on the Wayland we cannot determine absolute position of the window, we
need to use parent's window scale factor. For other platforms the GetDesktopToDeviceScaleByScreen is implemented
in nsBaseWidget.
Differential Revision: https://phabricator.services.mozilla.com/D7290
--HG--
extra : moz-landing-system : lando
