Some compositors such as GNOME mutter use heuristics to unredirect fullscreen
windows in an effort to reduce output latency. This works fine for applications
that take the proper steps to ensure all framebuffer updates happen in the
vblank interval. Since this is not currently the case for Firefox, bypassing
the compositor will lead to frame tearing.
Set _NET_WM_BYPASS_COMPOSITOR to 2 to opt out of fullscreen unredirection.
MozReview-Commit-ID: 1xW2VAnbiJw
--HG--
extra : rebase_source : 77c4ae490413057d8d9dadf9b155c86ddbbcb4b5
Also comment existing entries at nsWindow::GetCSDSupportLevel().
MozReview-Commit-ID: 1YzZhv7WrQj
--HG--
extra : rebase_source : c1dd1a3452e13e2479afee3c34d396757dae4cfd
Render titlebar button icons as a part of -moz-window-button-* appearence. It allows us to
theme the icons accordingly. We add a GtkImage widget to header bar buttons as Gtk+ does and
store icon pixel data there and render it at moz_gtk_header_bar_button_paint() as a part
of the buttons. It means that the toolbar buttons are not containers and
moz_gtk_get_widget_border() returns zero border for them.
Also implement GetToolbarButtonMetrics() per button.
MozReview-Commit-ID: gkAu3VmE3q
--HG--
extra : rebase_source : d1df34537901342969d1e33524b414a2786df541
Titlebar button on Gtk+ >= 3.20 can have defined its size as min-width and min-height
and can leave CSS styles border/padding empty. To render the button icon at center we need to
calculate button widget border from gap between icon and button.
This is done by GetToolbarButtonMetrics() which also stores final values to
ToolbarButtonGTKMetrics cache.
MozReview-Commit-ID: 5sMJATWHUNX
--HG--
extra : rebase_source : b0bda7c78106088a819b98c197cbb0cd099e47df
We need to use scaling factor of the monitor on which application is actually positioned.
Previously we used ScreenHelperGTK::GetGTKMonitorScaleFactor() which use the first monitor.
This does not work on hidpi+normal dpi monitors setup.
MozReview-Commit-ID: 1dVYOe48tPJ
--HG--
extra : rebase_source : af804d3104da91be459b219b261949d84b4f7c26
The GetSystemFontInfo() cannot return scaled value of the font by default monitor
scale factor. We need to scale it in nsLookAndFeel::GetFontImpl
by aDevPixPerCSSPixel like implementation for Windows does.
MozReview-Commit-ID: 5okD8vUu9UK
--HG--
extra : rebase_source : 39f3dec4acd434501860a8b716a42c45aadf3b61
Emulate what gtk+/gtkwindow.c gtk_window_present_with_time() does - use gdk_x11_display_get_user_time() on X11
and gtk_get_current_event_time() on Wayland to get event timestamp.
MozReview-Commit-ID: GEU6ZrQxq6v
--HG--
extra : rebase_source : db2f3ac03ae4ec9f9c1655cf682bff60a96dd3da
Firefox in Flatpak sandboxed environment does not get the list
of installed applications on the system because application should
know about the environment as little as possible. Introducing
nsFlatpakHandlerApp which forwards requests for opening downloaded files
to the system by utilizing gtk_show_uri fuction.
This changeset also removes nsIGIOMimeApp::Launch method from the interface
because it can be fully replaced with LaunchWithUri from nsIHandlerApp
interface.
The TMPDIR where files are downloaded when user choose to open them
needs to be accessible from sandbox and host. The default settings
TMPDIR=/tmp is accessible only to the sandbox.
To workaround for is to set TMPDIR environment variable to
$XDG_CACHE_HOME/tmp before executing Firefox.
MozReview-Commit-ID: CSBv0QcETpd
--HG--
extra : rebase_source : 8155c33fa9c402d2668bdfb07094ba6758fe6203
We don't add build-time dependency on Wayland libraries; that allows Wayland enabled Firefox
builds to run on systems without Wayland support.
We also can't dlsym() Wayland symbols directly from libwayland-client.so library as we miss
global data entries referenced by code at wayland-client.h then.
As a partial solution (for glibc systems only) we create dummy libwayland-client.so library
implementation and place it *after* Gtk+ 3.0 libraries at linking time.
It fixes build-time dependencies (we link against our libwayland-client.so library).
Run-time dependency is resolved by ld.so - when Gtk+ 3.0 libraries are linked with
system libwayland-client.so library, wayland symbols are pulled from there instead
from our dummy libwayland-client.so library.
When Gtk+ 3.0 is not linked with system libwayland-client.so it means we're running
on system without Wayland support. Our dummy libwayland-client.so implementation
is used (symbols are pulled run-time from there) and Firefox Wayland support is
disabled then.
MozReview-Commit-ID: IyaePwp4MxV
--HG--
extra : rebase_source : 852955d001657176e0bf69c099580be862d0b448
Make the clipboard data getter function more explicitly named and also create a counterpart to release clipboard data.
MozReview-Commit-ID: 3pWsQgCFDuG
--HG--
extra : rebase_source : c4eae554f5a24d998801550ac91b0859ac8e116e
nsWindow needs configuration change when rendering on Wayland:
- Always draw to mContainer on Wayland as we can't create custom subsurface for
mShell GdkWindow and listen events on mContainer then.
- GTK_WINDOW_TOPLEVEL can't be positioned on Wayland so create popup windows
as GTK_WINDOW_POPUP to control window position on Wayland.
- Create ePopupTypeMenu GdkWindow as GDK_WINDOW_TYPE_HINT_UTILITY instead of
GDK_WINDOW_TYPE_HINT_POPUP_MENU to create it as subsurface (Bug 1423598).
- Don't do pointer grab on Wayland (see Bug 1377084 for reference).
MozReview-Commit-ID: 6InzhTONtrD
--HG--
extra : rebase_source : 356112c2e8f80569ca4b2e41fa0747d71da21d89
Wayland compositors do not support GDK_DECOR_BORDER so use CSD decorations exclusively.
MozReview-Commit-ID: 8gzDcw2AumI
--HG--
extra : rebase_source : 4d319155d220420a768de619e7043dd56f6ee667
To have any effect we need to call gdk_window_set_decorations() on top-level GdkWindow only.
When rendering to mContainer the mGdkWindow belongs to mContainer so we need to get the window
from mShell explicitly.
MozReview-Commit-ID: KLKlVJbgg3
--HG--
extra : rebase_source : c17310949e067dca540bf269f12db135e6582ebc
When drawing to mContainer we still need to honor mShell as top-level window.
It means we have to listen property-notify-event there (as it's window specific),
get _NET_FRAME_EXTENTS here and use at nsWindow::SetWindowClass().
MozReview-Commit-ID: HYbNS0Lfyjy
--HG--
extra : rebase_source : f03cb4657a36238fd93b47b94ace48a325648296
WindowSurfaceWayland is Wayland implementation of WindowSurface class.
One WindowSurfaceWayland object manages drawing of one nsWindow so
those are tied 1:1. It implements base Lock() and Commit() interfaces
from WindowSurface. At Wayland side it represents one wl_surface object.
To perform visualiation of nsWindow, WindowSurfaceWayland contains
one wl_surface and two wl_buffer (by WindowBackBuffer) objects
(as we use double buffering). When nsWindow drawing is finished to
wl_buffer, the wl_buffer is attached to wl_surface and it's sent to
Wayland compositor.
MozReview-Commit-ID: 9NoamtF87e6
--HG--
extra : rebase_source : e942b28f1eaa4b1c24c6c4df6894db8d3d789e7e
wl_buffer is a main Wayland object with graphics data. wl_buffer basically represent one complete window screen.
When double buffering is involved every window (GdkWindow in our case) utilises two wl_buffers which are cycled.
One is filed with data by application and one is rendered by compositor.
WindowBackBuffer class manages one wl_buffer. It owns wl_buffer object, owns WaylandShmPool (which provides shared memory)
and ties them together.
MozReview-Commit-ID: v8Hlezo7oD
--HG--
extra : rebase_source : 40bffbbae2ee0c8f67d442ee2c5a62be43fafb44
We allocate shared memory (shm) by mmap(..., MAP_SHARED,...) as an interface between wayland based application
and wayland compositor. We draw our graphics data to the shm and handle to wayland compositor by wl_buffer/wl_surface.
WaylandShmPool acts as a manager of the allocated memory. Allocates it, holds reference to it and releases it.
MozReview-Commit-ID: CY6oEIl4Vxa
--HG--
extra : rebase_source : c43da8728e11e133cb021b1832382c1a39695a1a
Refactor ncClipboard::GetData() for better readability, add nsClipboard::SetTransferableData()
to send clipboard data to nsITransferable.
According to Gtk people [1] we can't mix free()/g_free() and malloc()/g_malloc() calls.
Existing nsClipboard code mixes that on some places which can lead to issued on glib built
with specific flags (ENABLE_MEM_PROFILE or ENABLE_MEM_CHECK).
[1] https://mail.gnome.org/archives/gtk-list/2000-July/msg00002.html
MozReview-Commit-ID: GvkUGSttVGO
--HG--
extra : rebase_source : 99801e1dc97e24a8d68fe7f3585562bb541c6628
Bug 1421974 introduced new mechanism to hide system titlebar by enabling client-side decorations for main Firefox window. It also causes a regression when the CSD window setup is enabled when system titlebar is hidden by window manager.
This patch fixes that and enables the CSD window setup only for case when it's actualy used.
MozReview-Commit-ID: AqfHR2bGr3K
--HG--
extra : rebase_source : 625366530922872af82e182db10f5069ebfa7dc4
Bug 1421974 introduced new mechanism to hide system titlebar by enabling client-side decorations for main Firefox window. It also causes a regression when the CSD window setup is enabled when system titlebar is hidden by window manager.
This patch fixes that and enables the CSD window setup only for case when it's actualy used.
MozReview-Commit-ID: 6OzoPyxlhCp
--HG--
extra : rebase_source : 9bcfc96cd27cb088f8d9671780304c2ac3772fdf
This patch is based on Karl Tomlinson's (:karlt) demo from Bug 1419456. We use gtk_window_set_titlebar()
to set invisible widget. The widget takes place of GtkHeaderBar which leads Gtk+ to render CSD shadows
and handle window resizing, it does not render any titlebar.
gtk_window_set_titlebar() works on unrealized windows only and mShell is already realized at time
of nsWindow::SetDrawsInTitlebar() call so we need to update recent GtkWidget setup.
In that case we create GdkWindow for mContainer (instead of mShell), create a temporary GtkWindow,
reparent mContainer (which owns mGdkWindow) to it, unrealize mShell and set up the titlebar
for mShell toplevel window.
As a workaround for Gtk+ Bug 791081 we also allocate some valid size for mShell before it's newly realized
with the updated titlebar.
MozReview-Commit-ID: A3KwRoOzoko
--HG--
extra : rebase_source : ded644762d3be9e79e3d407f57b2f9098021fb96
Enables override window manager default with those values:
MOZ_GTK_TITLEBAR_DECORATION=none - Firefox does not mess with decoration
MOZ_GTK_TITLEBAR_DECORATION=client - Firefox tries to disable titlebar rendering and draws shadows by client side decorations.
MOZ_GTK_TITLEBAR_DECORATION=system - Firefox tries to disable titlebar rendering and leave system (window manager) to draw window decorations.
MozReview-Commit-ID: G60QS3g1TD0
--HG--
extra : rebase_source : fd7b5d2b0282fbd54046947d210b1288a0610a23
We need apply various titlebar/border configuration which is based on active
window manager and desktop type. The XDG_CURRENT_DESKTOP shell variable contains active
desktop environment which we use at GetCSDSupportLevel().
Unfortunately Ubuntu adds "ubuntu:" prefix at XDG_CURRENT_DESKTOP so we can't do
plain string compare but rather search for DE substring at GetCSDSupportLevel().
MozReview-Commit-ID: GmAZ30p47eI
--HG--
extra : rebase_source : eeef51e7326bb8be6418554b07ce5791e988f02f
The browser.tabs.drawInTitlebar check at nsLookAndFeel is redundant, breaks Thunderbird and dynamic titlebar rendering change. Let's use browser.tabs.drawInTitlebar at browser level and when enabled configure titlebar visibility by moz_gtk* media atoms.
MozReview-Commit-ID: IhCYmXgVME7
--HG--
extra : rebase_source : 6f152e5c3d7d5abbb134c9f5adcb76fd6ed335cb
Adding MATE as FLAT as it does not support the shadow borders around the window.
GDK_DECOR_BORDER decoration mode means that the window manager renders borders around the window.
We want the border rendering for CSD_SUPPORT_FULL only which means the border looks like shadows. We don't wand WM to render solid/bold borders around main toplevel window.
MozReview-Commit-ID: BdwHi0LJRGC
--HG--
extra : rebase_source : 7b7d6733e62ae3188fe6cdeecca17de05b3d6873
