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
This makes balancing with gtk_style_context_restore()/ReleaseStyleContext()
unnecessary, and the style resolution cached in the style contexts is not
invalidated so frequently.
MozReview-Commit-ID: BKwyqoQsjv2
--HG--
extra : rebase_source : 4733d66f8265007555cc17568033ece09e6cb2dc
This makes balancing with gtk_style_context_restore()/ReleaseStyleContext()
unnecessary, and the style resolution cached in the style contexts is not
invalidated so frequently.
MozReview-Commit-ID: BKwyqoQsjv2
--HG--
extra : rebase_source : 44c82ff74e1e52046799659f3bfa37c7faafeb58
This makes balancing with gtk_style_context_restore()/ReleaseStyleContext()
unnecessary, and the style resolution cached in the style contexts is not
invalidated so frequently.
MozReview-Commit-ID: BKwyqoQsjv2
--HG--
extra : rebase_source : 2091fc84a9ecb8b55e7d3e36e72cbd03ea826ac8
This is necessary for GTK to match CSS rules against classes on ancestor nodes
of style contexts constructed from paths.
It can be tested with the following in ~/.config/gtk-3.0/gtk.css
tooltip.background label {padding: 100px;}
MozReview-Commit-ID: EUQ9ndeSl1Z
--HG--
extra : rebase_source : 95c267c5495791a40e755aacf14a80c750fbedd2
CreateStyleForWidget() then provides the same behavior with
g_style_context_save() as contexts from widget root style nodes.
MozReview-Commit-ID: 6lRCp3XOoRr
--HG--
extra : rebase_source : ad161eef11e0dc70c8a487c204f109eceac3b1c4