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
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
With an event filter method, we're logging all key events on any widgets to
check whether a key is pressed or not, to set
WidgetKeyboardEvent::mIsRepeat properly. If iBus and Fcitx work as expected,
they synthesize key events with setting their own modifier state which indicate
the events are synthesized by IME. In this expected case, synthesized key
events are not caught by the filter.
On the other hand, in some environment, they keep handling key events
asynchronously but they or something another module synthesizes key events
without the flag and such events are caught by the filter because the events
are posted into the event queue. Therefore, we decide that such synthesized
events are always generated by auto-repeat (first events which are always
filtered by IME are treated as first press, and then, synthesized events are
treated as repeated events because of no key release events).
This patch makes KeymapWrapper::FilterEvents() ignore coming KeyPress
events if:
- the time is exactly same as previous KeyPress event
- and IMContextWrapper instance is now waiting a GDK_KEY_PRESS event
- and hardware_keycode of waiting GDK_KEY_PRESS event is same as
keyCode of the KeyPress event
Differential Revision: https://phabricator.services.mozilla.com/D15380
--HG--
extra : moz-landing-system : lando
According to the log of bug 1498823, ibus won't set IBUS_IGNORED_MASK to
modifier flags when it synthesizes the event for asynchronous handling in
some environments.
Currently, we assume that iBus and Fcitx set IBUS_IGNORED_MASK or
FcitxKeyState_IgnoredMask. So, we put both real key events and synthesized
key events into the posting event queue and that causes using a lot of
memory until the editor is blurred. Fortunately, timestamp of synthesized
key events are always same as their original events. Therefore, we can look
for original event from the positing event queue.
Although we have gotten no bug reports about this issue of Fcitx, but this
patch adds same hack for Fcitx too because the runtime cost is not
expensive but the symptom is really serious.
Differential Revision: https://phabricator.services.mozilla.com/D15321
--HG--
extra : moz-landing-system : lando
It's not quaranteed that we have a valid wl_surface at GtkWidget::map event.
In that case create it at GtkWidget::map-event handler which is called after
widget show.
Differential Revision: https://phabricator.services.mozilla.com/D13979
--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
We can't listen on GdkDeviceManager as we need to track device changes here. Rvert back
the old working setup based on wl_seat listeners. Also check if the keyboard is already present
(before it's created here) to avoid memory leaks.
Differential Revision: https://phabricator.services.mozilla.com/D13727
--HG--
extra : moz-landing-system : lando
Some keyboard layouts which have dead keys may handle dead key composition
asynchronously. In this case, they don't rely on IME like iBus/Fcitx.
As far as I've tested, German (QWERTY) keyboard layout is one of such
keyboard layout. This returns true when gtk_im_context_filter_keypress()
is called for a base character input (like "a"). Then, it synthesizes
GDK_KEY_PRESS event without any key information such as:
> { type=GDK_KEY_PRESS, keyval=(null), unicode=0x0, state=, time=0,
> hardware_keycode=0, group=0 }
So, this is not marked as IBUS_IGNORED_MASK nor FcitxKeyState_IgnoredMask
by IME, but we should ignore this event since we should've already dispatched
"keydown" event for the preceding "a" key event, and anyway "keydown" event
for the synthesized event does not make sense for any web apps.
This patch makes IMContextWrapper::OnKeyEvent() ignore such key event, i.e.,
when it's in a dead key sequence, and GDK_KEY_PRESS does not have enough
information, e.g., hardware_keycode shouldn't be 0 especially for printable
keys. Therefore, this patch make it check only hardware_keycode value and
gdk_keyval_to_unicode(aEvent->keyval) value.
If some keyboard layouts would send the original key event as is, we would
need to do more, but currently, this is enough and safe to land this timing.
Differential Revision: https://phabricator.services.mozilla.com/D13656
--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
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--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
The intent of the test is to barf at configure time when the target
system doesn't use the glibc. The reason behind this is that the setup
with the mozwayland stub library relies on the dynamic linking order
the glibc uses.
However, the test checks GLIB_LIBS, which is the result of pkg-config
--libs for *GLIB*, not glibc, and all Gtk builds use glib, irrespective
of the libc in use. Practically speaking, this means the error branch
can't ever be taken... except on artifact builds, because we don't run
pkg-config tests there.
The dynamic linking order problem only really matter when wayland is
enabled at runtime, which it isn't by default. We'll eventually have to
sort it out for tier 3 platforms, but the current moz.build doesn't do
anything for them anyways.
Differential Revision: https://phabricator.services.mozilla.com/D12074
--HG--
extra : moz-landing-system : lando
Right now CreateDataFromPrimitive doesn't use the aDataLen parameter, and after this change the out
value should be the same as the value passed in, as long as we are dealing with strings.
Differential Revision: https://phabricator.services.mozilla.com/D10718
--HG--
extra : moz-landing-system : lando
Keep our old 'progressbar' as an alias for now, but unship
'progresschunk' by restricting it to UA/chrome sheets only.
Unship 'progresschunk-vertical' by removing it since it's
not used internally for anything.
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
I verified that we can still copy from Firefox to an older version of Firefox without this patch.
LibreOffice also still works. Talking to some GTK people on IRC they are also happy about UTF-8 instead of wrongly declared UCS2.
Differential Revision: https://phabricator.services.mozilla.com/D8467
--HG--
extra : moz-landing-system : lando
I verified that we can still copy from Firefox to an older version of Firefox without this patch.
LibreOffice also still works. Talking to some GTK people on IRC they are also happy about UTF-8 instead of wrongly declared UCS2.
Differential Revision: https://phabricator.services.mozilla.com/D8467
--HG--
extra : moz-landing-system : lando
This patch makes Firefox's GTK3 platform support use GtkFileChooserNative when
available. GtkFileChooserNative transparently uses the desktop portals
interface, which enables Firefox to use native Qt file dialogs on KDE, or
sandboxed file dialogs in Flatpak.
Differential Revision: https://phabricator.services.mozilla.com/D7033
--HG--
extra : moz-landing-system : lando
I verified that we can still copy from Firefox to an older version of Firefox without this patch.
LibreOffice also still works. Talking to some GTK people on IRC they are also happy about UTF-8 instead of wrongly declared UCS2.
Differential Revision: https://phabricator.services.mozilla.com/D8467
--HG--
extra : moz-landing-system : lando
This is based on patch by Mike Conley (:mconley)
The left/right toolbox placement can be adjusted later as we know at toolkit level where the buttons are
so we can set border/padding accordingly.
Depends on D8529
Differential Revision: https://phabricator.services.mozilla.com/D8549
--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
This patch makes Firefox's GTK3 platform support use GtkFileChooserNative when
available. GtkFileChooserNative transparently uses the desktop portals
interface, which enables Firefox to use native Qt file dialogs on KDE, or
sandboxed file dialogs in Flatpak.
Differential Revision: https://phabricator.services.mozilla.com/D7033
--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
Masayuki Nakano
Doug Thayer
Martin Stransky
Tom Schuster
Tooru Fujisawa
Emilio Cobos Álvarez
Sylvestre Ledru
Dorel Luca
shindli
Benjamin Bouvier
Andreea Pavel
Ehsan Akhgari
Ryan Hendrickson
Gabriele Svelto
Noemi Erli
Coroiu Cristina
Mats Palmgren
Csoregi Natalia
Mike Hommey
Mike Conley
arthur.iakab
Jonathan Watt
Daosheng Mu
Jan Horak
Jan Beich
Narcis Beleuzu
sotaro
Nathan Moos
Ciure Andrei
Tim Nguyen
Neil Deakin