Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
This remotes the APZInputBridge interface over the PAPZInputBridge
protocol in the case of the GPU process, and makes the GPU process'
main thread act as the APZ controller thread in that process. If
there is no GPU process we continue as before and the APZInputBridge
interface implementation is the concrete APZCTreeManager instance
in the UI process.
The main changes in this patch are moving all the code associated with
these messages out of APZCTreeManager{Parent,Child} and into
APZInputBridge{Parent,Child}. APZCTreeManagerChild now returns an
APZInputBridgeChild instance via InputBridge(), instead of returning
itself. The SetControllerThread call in the GPU process is also updated.
MozReview-Commit-ID: M4AaIW1Q0h
--HG--
extra : rebase_source : e5a8f14e23be34229fe80a47f6789d19b19e0a9f
This separates the methods that are used to deliver input events
synchronously over IPDL to the compositor; this interface will be
remoted over a new APZInputBridge IPDL protocol in future patches.
MozReview-Commit-ID: 1f3V9SUKlfW
--HG--
rename : gfx/layers/apz/public/IAPZCTreeManager.cpp => gfx/layers/apz/src/APZInputBridge.cpp
extra : rebase_source : 523abce7949baf9e3b7803a61632eb4434a6967f
Currently the ZoomToRect function is only ever called on Android, on the
UI process main thread, which is neither the controller nor the sampler
thread. Instead of allowing "random" threads to run inside APZ, we
ensure that callers run it on the controller thread.
Since we can have multiple browser windows on multiple different
displays with different DPIs, it doesn't make sense to have a single
static DPI value shared across all APZCTreeManagers. Instead, each
APZCTM should store its own DPI value for the display the window is on.
Since the DPI is only ever read from the controller thread, we can make
it bound to that thread, and update the setter code to also set it on
that thread.
As with the previous patch, the change in APZCTreeManagerParent is a
no-op but allows making some other thread in the GPU process the controller
thread. And the change in nsBaseWidget is a no-op everywhere except
Android.
- The change in APZCTreeManagerParent is functionally a no-op because it
only ever runs in the GPU process on the controller thread. But it
allows moving the controller thread to some other thread.
- The change in nsBaseWidget is a no-op for desktop platforms, because
in the UI process the main thread is the controller thread. But on
Android it moves the call from the main thread to the Java UI thread.
Currently the ZoomToRect function is only ever called on Android, on the
UI process main thread, which is neither the controller nor the sampler
thread. Instead of allowing "random" threads to run inside APZ, we
ensure that callers run it on the controller thread.
MozReview-Commit-ID: 64LkHaFLIOl
--HG--
extra : rebase_source : 61f397c0e18f83c68c228879692c9d4767b25675
Since we can have multiple browser windows on multiple different
displays with different DPIs, it doesn't make sense to have a single
static DPI value shared across all APZCTreeManagers. Instead, each
APZCTM should store its own DPI value for the display the window is on.
Since the DPI is only ever read from the controller thread, we can make
it bound to that thread, and update the setter code to also set it on
that thread.
As with the previous patch, the change in APZCTreeManagerParent is a
no-op but allows making some other thread in the GPU process the controller
thread. And the change in nsBaseWidget is a no-op everywhere except
Android.
MozReview-Commit-ID: CB23MxGISeL
--HG--
extra : rebase_source : b3358202ec5fa27422c56ae1b0b2237dbc8e489b
- The change in APZCTreeManagerParent is functionally a no-op because it
only ever runs in the GPU process on the controller thread. But it
allows moving the controller thread to some other thread.
- The change in nsBaseWidget is a no-op for desktop platforms, because
in the UI process the main thread is the controller thread. But on
Android it moves the call from the main thread to the Java UI thread.
MozReview-Commit-ID: LVVZLFxSuyj
--HG--
extra : rebase_source : 89e9c8824c31867ad92152ff9b496744a6afdd83
IIIMF is really old IME framework. In these days, it's not used as default IM
module of any major distributions. However, ATOK X which is old proprietary
IME requires IIIMF and it's still used by some Japanese IME users. Therefore,
we need to take back the hack to prevent crash caused by IIIMF.
We did increment refcount of GtkIMContextIIIM class to prevent IIIM module
from being unloaded. However, it was not ported when we changed default
toolkit from GTK2 to GTK3. So, this is doing the porting.
Unfortunately, the instance of GtkIMContextIIIM is wrapped by opacity struct.
So, it's not safe to access the pointer with declaring a mimic struct.
Therefore, we should directly get GType from the name with calling
g_type_from_name("GtkIMContextIIIM") instead of using G_TYPE_FROM_INSTANCE()
and g_type_name().
MozReview-Commit-ID: GCZaSUtPiS9
--HG--
extra : rebase_source : 3b959023bf47fa26393fc04e722c9da79a50991d
uim is an old IM which uses key snooper to listen to key events rather than
via filter key event API which should be called by applications. It's still
used by Debian 9.x, so, we still need to support this.
Unfortunately, we cannot detect if uim actually uses key snooper because it's
switch by build option of uim. Currently, Debian builds uim as using key
snooper. So, we should assume uim uses key snooper always. On the other
hand, somebody *might* use uim built as not using key snooper, so, let's
decide if uim uses key snooper with new pref,
"intl.ime.hack.uim.using_key_snooper", but its default should be true.
Note that ibus and Fcitx also have the mode to use key snooper (perhaps for
backward compatibility with uim). However, it's not enabled in default
settings and even if it's enabled, Firefox is in whitelist in the default
settings of them for stop using key snooper. Therefore, we don't need to
support key snooper mode for them unless we'll get some requests to
support their key snooping mode.
MozReview-Commit-ID: 6fTsfKrHzvo
--HG--
extra : rebase_source : 8ddf4541db635246e6bb0ddc73b012c9be001c6d
CLAMP is unnecessary as the minimum acceptable value is 0, and
progressPercent is unsigned. CLAMP can trigger the following warning/error in some builds:
error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
--HG--
extra : rebase_source : 0dfcf4286a74adac03f7498f1d35fee069528826
TSF doesn't send WM_KEYDOWN nor WM_KEYUP to us while it handles a key message
with ITfKeystrokeMgr::KeyDown() or ITfKeystrokeMgr::KeyUp(). Therefore,
TSFTextStore needs to store handling key event message during calling
those methods and if it does something, we need to dispatch eKeyDown event
or eKeyUp event before dispatching any events.
However, we shouldn't dispatch WidgetKeyboardEvent during a document lock
because TSF/TIP do not assume that document is broken during a document lock.
Therefore, TSFTextStore needs to put it as a pending action into the queue.
So, this patch wraps this with
TSFTextStore::MaybeDispatchKeyboardEventAsProcessedByIME(). It checks if
there is a document lock when it's called. If it's locked (and not yet
dispatched keyboard event for the handling key message), it adds pending
action to dispatch keyboard event later. Otherwise, (and not yet dispatched
one), it dispatches keyboard event directly.
MozReview-Commit-ID: 9rJTJykVLyf
--HG--
extra : rebase_source : 4f8297b2b9fe2905e4cd1f64086fcdbe3d0b6035
On Android, GeckoEditableSupport has already dispatched eKeyDown event and
eKeyUp event even during composition. I.e., the pref which will be enabled
by bug 354358 has already been set to true only on Android.
On the other hand, GeckoEditableSupport does not dispatch them if content
listens to "input", "compositionstart", "compositionupdate" or
"compositionend". So, different from the other platforms, we need additional
pref to make the new behavior behind pref.
Therefore, this patch adds a new pref,
"intl.ime.hack.on_any_apps.fire_key_events_for_composition", to override
existing "intl.ime.hack.on_ime_unaware_apps.fire_key_events_for_composition"
pref. And sets mKeyCode and mKeyNameIndex of the dummy KeyboardEvents to
NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process.
MozReview-Commit-ID: Fuy0Ir2xiO5
--HG--
extra : rebase_source : c76b613ea186458ebdf0d67f4bc984e8ac5f1041
ibus and fcitx usually post key event to other IME process, then, if it causes
some signals to updating composition string, they may not send the posted
key event to us again. Then, IMContextWrapper dispatches neither eKeyDown nor
eKeyUp event since mProcessingKeyEvent becomes non-nullptr only while
OnKeyEvent() is called. So, IMContextWrapper need to store key event if
OnKeyEvent() assumes that given key event is posted to different process.
Then, if IMContextWrapper receives some signals, it should dispatch eKeyDown
and eKeyUp event with stored key event.
Note that we cannot compare the pointer of first event and following event
directly even though usually both events are same address as far as I checked
because according to the source code of ibus, fcitx and GDK, they use
gdk_event_copy() to keep storing original event. According to the document of
the API, it might just increment refcount. However, the actual implementation
of the API always creates another instance and return it. So, it might be
used same address by arena allocation or something accidentally. Anyway,
we shouldn't compare them. Instead, we need to compare each information of
two key events. Unfortunately, we also cannot compare them simply. Both
ibus and fcitx set unused bits of GdkEventKey::state to true when they send
back the event to us. Therefore, we should compare some of or all of the
members by ourselves. I think that matching time must be enough in most
cases since its value of native key events are properly set. However, for
safer code, this patch also checks type, keyval and part of state.
MozReview-Commit-ID: FZSwN61v0Sd
--HG--
extra : rebase_source : e57a654392f476f5ec52d82bdd238eed2eb91e83
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
First of all, TextInputHandler::HandleKeyDown() dispatches an eKeyDown event
before sending IME. This is different behavior from Gecko on the other
platforms and it means TextInputHandler does not know if the eKeyDown event
will be handled by IME. Therefore, we need to make TextInputHandler dispatch
an eKeyDown event dispatch when it needs to dispatch another event. Therefore,
this patch makes TextInputHandler not dispatch an eKeyDown even from
its HandleKeyDown() unless it's already has composition (because if it's
already had composition, any eKeyDown event except modifier keys should be
marked as "processed by IME" for compatibility with the other browsers).
For dispatching eKeyDown event only once for a native keydown event,
this patch implements TextInputHandlerBase::MaybeDispatchCurrentKeydownEvent()
to check whether eKeyDown event has already been dispatched for the event
and if it's not so, dispatches eKeyDown event.
Note that on macOS, dead keys are implemented as IME. However, we need to
treat dead keys as is. Therefore, if current keydown event is a dead keydown
event, MaybeDispatchCurrentKeydownEvent() should NOT mark dispatching
eKeyDown event and its following eKeyDown event as "processed by IME".
MozReview-Commit-ID: 7epk8wdAznd
--HG--
extra : rebase_source : 0ed30ff3e108170fd96eabe626e0530473f2f3b1
Currently, IMContextWrapper doesn't dispatch eKeyDown event and eKeyUp event
if it's handled by IME. However, for conforming to UI Events, it should
not eat given keyboard events completely.
This patch makes IMContextWrapper dispatches eKeyDown event or eKeyUp event
before dispatching first event of composition events or content command
event.
MozReview-Commit-ID: H2jHpViTH5Q
--HG--
extra : rebase_source : a1f4127ba87e03e1ff97690f97fb7bf64b4d4818
For conforming UI Events spec, KeymapWrapper::InitKeyEvent() should initialize
mKeyCode and mKeyNameIndex with NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process if
given keyboard event has already been handled by IME.
For making it know if given keyboard event has been handled by IME, this patch
adds additional bool argument to it and its callers.
Note that this patch changes keyCode value and key value of "keydown" event if
it's fired before "compositionstart" since Chromium does so on Linux.
MozReview-Commit-ID: FC3tfyeeopU
--HG--
extra : rebase_source : b7e2a70db1fbb4ca7d20379fd1c14f7dc38e656d
Some themes (Adwaita for instance) draws bold dark line at
titlebar bottom. It does not fit well with Firefox tabbar UI so
draw themed titlebar with some extent to make the titlebar
bottom part invisible (it's clipped by cairo).
MozReview-Commit-ID: 3rs4UzFJdPa
--HG--
extra : rebase_source : ca9270f549a3106711afac8ee0c7a30839ab2bf3
uim is an old IM which uses key snooper to listen to key events rather than
via filter key event API which should be called by applications. It's still
used by Debian 9.x, so, we still need to support this.
Unfortunately, we cannot detect if uim actually uses key snooper because it's
switch by build option of uim. Currently, Debian builds uim as using key
snooper. So, we should assume uim uses key snooper always. On the other
hand, somebody *might* use uim built as not using key snooper, so, let's
decide if uim uses key snooper with new pref,
"intl.ime.hack.uim.using_key_snooper", but its default should be true.
Note that ibus and Fcitx also have the mode to use key snooper (perhaps for
backward compatibility with uim). However, it's not enabled in default
settings and even if it's enabled, Firefox is in whitelist in the default
settings of them for stop using key snooper. Therefore, we don't need to
support key snooper mode for them unless we'll get some requests to
support their key snooping mode.
MozReview-Commit-ID: 6fTsfKrHzvo
--HG--
extra : rebase_source : 8ddf4541db635246e6bb0ddc73b012c9be001c6d
ibus and fcitx usually post key event to other IME process, then, if it causes
some signals to updating composition string, they may not send the posted
key event to us again. Then, IMContextWrapper dispatches neither eKeyDown nor
eKeyUp event since mProcessingKeyEvent becomes non-nullptr only while
OnKeyEvent() is called. So, IMContextWrapper need to store key event if
OnKeyEvent() assumes that given key event is posted to different process.
Then, if IMContextWrapper receives some signals, it should dispatch eKeyDown
and eKeyUp event with stored key event.
Note that we cannot compare the pointer of first event and following event
directly even though usually both events are same address as far as I checked
because according to the source code of ibus, fcitx and GDK, they use
gdk_event_copy() to keep storing original event. According to the document of
the API, it might just increment refcount. However, the actual implementation
of the API always creates another instance and return it. So, it might be
used same address by arena allocation or something accidentally. Anyway,
we shouldn't compare them. Instead, we need to compare each information of
two key events. Unfortunately, we also cannot compare them simply. Both
ibus and fcitx set unused bits of GdkEventKey::state to true when they send
back the event to us. Therefore, we should compare some of or all of the
members by ourselves. I think that matching time must be enough in most
cases since its value of native key events are properly set. However, for
safer code, this patch also checks type, keyval and part of state.
MozReview-Commit-ID: FZSwN61v0Sd
--HG--
extra : rebase_source : e54284c27a171f899a6cf87a65935669e2d57021
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
Bogdan Tara
Boris Zbarsky
Jeff Muizelaar
James Willcox
Kartikaya Gupta
Eitan Isaacson
Sylvestre Ledru
Coroiu Cristina
Adrian Wielgosik
Markus Stange
Masayuki Nakano
Andreea Pavel
Xidorn Quan
Michael Webster
arthur.iakab
Gurzau Raul
Hector Zhao
Martin Stransky
Dorel Luca