Cleans up the code a bit to make actually used fallback code easier to spot
and update the required GTK version so deprecation warnings are more accurate.
Also make `gdk_window_set_opaque_region` always available - we can now assume
it to be present in all supported versions.
Differential Revision: https://phabricator.services.mozilla.com/D82804
Use gdk_window_set_geometry_hints() instead of gtk_window_set_geometry_hints() as gdk_*
does not set base sizes which breaks KDE and other window managers.
Differential Revision: https://phabricator.services.mozilla.com/D61552
--HG--
extra : moz-landing-system : lando
Usually we update mBounds from OnSizeAllocate() which is called
by Gtk when mContainer changes its actual size.
However we need to set mBounds in advance at Resize() as JS
code expect immediate window size change. When Resize() is called between
SetSizeMode() calls (which maximize/unmaximize the window) we can miss
OnSizeAllocate() Gtk call as actual mContainer size may not change
from Gtk perspective and we end up with incorrect mBounds.
To compensate it call OnSizeAllocate() explicitly also
from OnConfigureEvent() after size mode change.
Differential Revision: https://phabricator.services.mozilla.com/D55941
--HG--
extra : moz-landing-system : lando
Usually we update mBounds from OnSizeAllocate() which is called
by Gtk when mContainer changes its actual size.
However we need to set mBounds in advance at Resize() as JS
code expect immediate window size change. When Resize() is called between
SetSizeMode() calls (which maximize/unmaximize the window) we can miss
OnSizeAllocate() Gtk call as actual mContainer size may not change
from Gtk perspective and we end up with incorrect mBounds.
To compensate it call OnSizeAllocate() explicitly also
from OnConfigureEvent().
Differential Revision: https://phabricator.services.mozilla.com/D55941
--HG--
extra : moz-landing-system : lando
Using gtk_targets_include_text actually leads to a small behavior difference,
because gtk_targets_include_text also includes text/plain.
But gtk_selection_data_set_text seems to correctly convert UTF-8 to plain text.
Differential Revision: https://phabricator.services.mozilla.com/D8283
--HG--
extra : moz-landing-system : lando
Based on a patch from Marco Pesenti Gritti (11 years ago)
Depends on D7407
Differential Revision: https://phabricator.services.mozilla.com/D7408
--HG--
extra : moz-landing-system : lando
IME (e.g., fcitx) may refer selection colors of widget under window which
is associated with IM context to support any colored widget. So, IME
expects good selection colors which have sufficient contrast between
foreground and background, and also selection background color and
widget background color like GtkTextView. However, some desktop themes
set our widget to different selection colors from GtkTextView which may
be unreadable.
nsTextFrame (which paints composition string) expects that composition
string colors coming from IME are sufficiently readable and background
color of composition string and background color of our editor's default
style (coming from LookAndFeel) have sufficient contrast because
nsTextFrame assmes that composition string colors coming from IME are
decided for the default style.
Therefore, this patch creates SelectionStyleProvider which overwrites
selection style of our widget with selection style of GtkTextView so
that IME can refer selection colors of GtkTextView via our widget.
MozReview-Commit-ID: 5vdcSgoEYv0
--HG--
extra : rebase_source : edf375ac393a72d3e44839a76d5c44b6db12dc63
ibus and fcitx have asynchronous key event handling mode and it's enabled in
default settings. That is, when they receive a key event from application via
a call of gtk_im_context_filter_keypress(), they may post the key event
information to other IME process, then does nothing but store the copy of the
event with gdk_event_copy() and returns true for the result of
gtk_im_context_filter_keypress(). When the other IME process handles the
event, returns the result to them in our process. Then, they send the stored
key event to us again. Finally, they actually handles the event in our process
actually.
Therefore, we may receive every key event twice. So, this causes dispatching
eKeyDown event and eKeyUp event twice. Preceding key event is always marked
as "processed by IME" since gtk_im_context_filter_keypress() returns true
temporarily and following key event is dispatched as expected. So, we need
to ignore the first event only when gtk_im_context_filter_keypress() returns
true but the event is posted to different process.
Unfortunately, we cannot know if the key event is actually posted to different
process directly. However, we can know if active IM is ibus, fcitx or another
one and if ibus or fcitx is in asynchronous key handling mode.
The former information is provided by gtk_im_multicontext_get_context_id().
It returns a string which is set to the IM multicontext instance by creator.
We'll get "ibus" if IM is ibus, get "fcitx" if IM is fcitx.
The latter information is not provided. However, they consider the mode from
env value. ibus checks IBUS_ENABLE_SYNC_MODE. fcitx checks both
IBUS_ENABLE_SYNC_MODE and FCITX_ENABLE_SYNC_MODE.
Additionally, we can know if received key event has already been posted to
other IME process. They use undefined bit of GdkEventKey::state to store
if the key event has already been posted (1 << 25, they called "ignored" flag).
Although their approach is really hacky but we can refer the information at
least for now.
Finally, when we guess a key event is posted to other IME process, let's
IMContextWrapper::OnKeyEvent() not dispatch eKeyDown nor eKeyUp event.
Note that if it's handled synchronously as unexpected, it may causes
dispatching one or more composition events and/or delete content event.
So, in such case, we dispatch a keyboard event for processing key event
anyway. There is only once case we'll fail to dispatch keyboard event.
If we receive signals to dispatch composition events or delete content
command event when IM receives the result from other IME process but
it doesn't send the key event to us. This will be fixed by the following
patch.
MozReview-Commit-ID: 94PrlnmQ3uJ
--HG--
extra : rebase_source : fc31b0293ff0f0688dd39b0094fdf8f98b6c64d3
ibus and fcitx have asynchronous key event handling mode and it's enabled in
default settings. That is, when they receive a key event from application via
a call of gtk_im_context_filter_keypress(), they may post the key event
information to other IME process, then does nothing but store the copy of the
event with gdk_event_copy() and returns true for the result of
gtk_im_context_filter_keypress(). When the other IME process handles the
event, returns the result to them in our process. Then, they send the stored
key event to us again. Finally, they actually handles the event in our process
actually.
Therefore, we may receive every key event twice. So, this causes dispatching
eKeyDown event and eKeyUp event twice. Preceding key event is always marked
as "processed by IME" since gtk_im_context_filter_keypress() returns true
temporarily and following key event is dispatched as expected. So, we need
to ignore the first event only when gtk_im_context_filter_keypress() returns
true but the event is posted to different process.
Unfortunately, we cannot know if the key event is actually posted to different
process directly. However, we can know if active IM is ibus, fcitx or another
one and if ibus or fcitx is in asynchronous key handling mode.
The former information is provided by gtk_im_multicontext_get_context_id().
It returns a string which is set to the IM multicontext instance by creator.
We'll get "ibus" if IM is ibus, get "fcitx" if IM is fcitx.
The latter information is not provided. However, they consider the mode from
env value. ibus checks IBUS_ENABLE_SYNC_MODE. fcitx checks both
IBUS_ENABLE_SYNC_MODE and FCITX_ENABLE_SYNC_MODE.
Additionally, we can know if received key event has already been posted to
other IME process. They use undefined bit of GdkEventKey::state to store
if the key event has already been posted (1 << 25, they called "ignored" flag).
Although their approach is really hacky but we can refer the information at
least for now.
Finally, when we guess a key event is posted to other IME process, let's
IMContextWrapper::OnKeyEvent() not dispatch eKeyDown nor eKeyUp event.
Note that if it's handled synchronously as unexpected, it may causes
dispatching one or more composition events and/or delete content event.
So, in such case, we dispatch a keyboard event for processing key event
anyway. There is only once case we'll fail to dispatch keyboard event.
If we receive signals to dispatch composition events or delete content
command event when IM receives the result from other IME process but
it doesn't send the key event to us. This will be fixed by the following
patch.
MozReview-Commit-ID: 94PrlnmQ3uJ
--HG--
extra : rebase_source : 0bb58ed432bacef8ad13264babd2b21fe950b71c
When we perform copy -> paste in one Firefox process on Wayland we're locked because Wayland clipboard paste
operation just reads data from filedescriptor and does not run main event loop.
A solution is to use Gtk+ shortcut here, when clipboard selection owner is the same as data receiver.
Gtk+ then does not go through X11/Wayland but calls clipboard data getter callback directly,
which we can use on Wayland because it also does not main event loop and the operation
stays synchronous.
MozReview-Commit-ID: G8myCBUSzxb
--HG--
extra : rebase_source : 34cb3095be4b2f00d19c589dc5f676b1b895eb15
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
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
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
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
GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=747634
Before 3.16.3, GDK cannot override classname by --class command line option
when program uses gdk_set_program_class(). So if 3.16.3+, we should call
gdk_set_program_class() to set program class name of default.
MozReview-Commit-ID: KvNc3U6xHr7
--HG--
extra : rebase_source : aae14973022bb29eb89787b67323a845763c0650
For X11 only builds get display from DISPLAY env variable or from command line argument. For Wayland enabled buils use standard gdk_display_manager_open_display() path which respects GDK_BACKEND.
When command line argument --display is given pass it to child process by MOZ_GDK_DISPLAY env variable.
MozReview-Commit-ID: F9jEaJ9SU1p
--HG--
extra : rebase_source : 31cf96bcdfe5c525625aa3742aa74ec674265fe1
Jonathan Kew
Robert Mader
Mike Conley
Coroiu Cristina
jayati
Andreea Pavel
Martin Stransky
Ben Iofel
Csoregi Natalia
Tim Nguyen
Sylvestre Ledru
Gurzau Raul
Tom Schuster
Ehsan Akhgari
Cosmin Sabou
Masayuki Nakano
James Willcox
Dorel Luca
Jan Steffens
decltype
Jan Horak
Bogdan Tara
Makoto Kato
Chris Coulson