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
Let's use GtkInputPurpose and GtkInputHints by inputmode for software keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D67771
--HG--
extra : moz-landing-system : lando
Let's use GtkInputPurpose and GtkInputHints by inputmode for software keyboard.
Depends on D67770
Differential Revision: https://phabricator.services.mozilla.com/D67771
--HG--
extra : moz-landing-system : lando
It is useful to use ToString.h to log text and selection change instead of
adding it each source code. Actually, there is same code in
IMEContentObserver and widget.
Also, mozilla namespace is required since this conflicts with
WinModifierKeyState.h.
Differential Revision: https://phabricator.services.mozilla.com/D64021
--HG--
extra : moz-landing-system : lando
At bug 1614208, the line style value mapping was changed, but
`GeckoEditable.IME_RANGE_LINE_*` are not updated.
This patch makes the style in `TextRangeStyle` an enum class for making it
type safer, and updates `GeckoEditable.IME_RANGE_LINE_*`, and finally, adds
`FYI` comments in `TextRangeStyle` to make developers realize it requires
manual update.
Differential Revision: https://phabricator.services.mozilla.com/D62883
--HG--
extra : moz-landing-system : lando
This should be an idempotent patch. The way to come up with this patch has been:
* Run the first script attached to the bug and pipe it to xclip, then paste it
in color.rs
* Add the relevant #[derive] annotations and remove the color.mako.rs
definition.
* Reorder the values to match the ColorID definition, on which some widget
prefs and caching stuff relies on.
* Manually port some documentation from nsLookAndFeel.h
* Run `rg 'eColorID_' | cut -d : -f 1 | sort | uniq >files`
* Run the second script attached to the bug.
* Manually fix usage of `LAST_COLOR` (adding the `End` variant), and adding
casts to integer as needed.
* Add an static assert so that people remember to update the prefs, rather than
a comment on the definition :)
Differential Revision: https://phabricator.services.mozilla.com/D32610
--HG--
extra : moz-landing-system : lando
We've ignored clauses whose visual styles are not specified.
However, kinput2 with XIM protocol does not specify any styles
to non-selected clauses. Therefore, we fail to dispatch
eCompositionChange events if there is 2 or more clauses.
Note that the log in the bug indicates that we may set
selected clause type to`TextRangeType::eConvertedClause` and
last clause type to `TextRangeType::eSelectedClause` because
caret is always put at end of composition string. However,
this should not problem for now because nobody except plugins
on Windows refer this information.
Differential Revision: https://phabricator.services.mozilla.com/D23464
--HG--
extra : moz-landing-system : lando
On Wayland, `gtk_im_multicontext_get_context_id()` returns
`"wayland"`. However, we need to know actual IM which works
behind Wayland. Fortunately, `XMODIFIERS` env includes IME
name like "xim" case. Therefore, we can refer it instead.
Differential Revision: https://phabricator.services.mozilla.com/D23469
--HG--
extra : moz-landing-system : lando
Unfortunately, we're not sure whether ibus always handles non-dead key events
asynchronously or synchoronously. Therefore, for safer fix, this patch makes
IMContextWrapper::OnKeyEvent() decide that with the result of
gtk_im_context_filter_keypress(). If active IME is ibus and it consumes non-
synthesized events on password fields, it adjusts probablyHandledAsynchronously
value.
So, this patch changes the behavior of only when:
- active IME is ibus.
- only when a password field or ime-mode:disabled field has focus.
- not in dead key sequence.
- and the key event is consumed by ibus but nothing happend.
This must be enough safe to uplift.
Differential Revision: https://phabricator.services.mozilla.com/D18635
--HG--
extra : moz-landing-system : lando
Now, we believe that when `maybeHandledAsynchronously` is set to true,
ibus handles the event asynchronously in usual cases. However, the behavior
of ibus on password field is unclear. Currently, on Ubuntu 18.04,
Ubuntu 18.10 and Debian Cinnamon (9.6 / 3.2.7), ibus handles key events
asynchronously even in password fields even though I confirmed it was not
so at initial fix. So, it could be just my mistake, but we need to prepare
for both cases here for safer fix.
So, in the following patch, I need to add another variable for weaker
decision, and we treat `maybeHandledAsynchronously` stronger than its
nuance. Therefore, this patch renames it to `probablyHandledAsynchronously`.
Differential Revision: https://phabricator.services.mozilla.com/D18634
--HG--
extra : moz-landing-system : lando
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
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
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
- 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
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
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
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
Different from Windows and macOS, we cannot check if active keyboard layout
works as "IME" actually. Therefore, this patch add the telemetry probe
to the dispatcher of eCompositionStart. However, composition string is also
used by some Wester keyboard layouts which have dead keys. So, the meaning
of the result is deferent from the other platforms, but it must be useful
information which IM (e.g., fcitx, ibus) is used by most users.
MozReview-Commit-ID: A7vYuGtcrRw
--HG--
extra : rebase_source : 1f0948b58b999eee4b539d7db05d455b34f4be72
On some Linux environment, GTK_IM_MODULE env may be "xim". Then, actual
IM is specified with XMODIFIERS env with "@im=". Therefore, if active IM
context ID is xim, IMContextWrapper::Init() needs to look for actual IM name
in XMODIFIERS.
MozReview-Commit-ID: 1aGjBkF4AQn
--HG--
extra : rebase_source : 8c50baa517c61ec2d872c036abc989b4a07e8e36
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
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
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
On Linux, dead key is implemented with "table-based input methods" which are
available even on GtkIMContextSimple (i.e., available even in password fields).
Therefore, IMContextWrapper handles dead key sequence as usual composition of
IME. However, on the other platforms, we dispatch "Dead" eKeyDown and eKeyUp
events for dead key.
We started to mark keyboard events which are handled by IME as "processed by
IME" since bug 1343451, i.e., we started to set mKeyNameIndex to
KEY_NAME_INDEX_Process. However, we should keep previous behavior, i.e., keep
setting it to KEY_NAME_INDEX_Dead. Fortunately, GDK's key event tells us
whether the keyboard event is a dead key event with keysym. So, we can detect
if we're in a dead key sequence simply.
MozReview-Commit-ID: Dv336WptfXN
--HG--
extra : rebase_source : e8a7b5a7eb7c57e1e45de20ebebd56f88457cfc6
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
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 : 4129620126a34e27af1503e7c4652bb09c7e9bb6
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 : 9c88967b8e2a5539023deb1277ae8704418dfd0d
Robert Mader
Makoto Kato
Dorel Luca
Simon Giesecke
Bogdan Tara
Masayuki Nakano
Xidorn Quan
Henri Sivonen
Alex Henrie
Emilio Cobos Álvarez
Sylvestre Ledru
Martin Stransky
Tooru Fujisawa
Benjamin Bouvier
Chris Peterson
Cosmin Sabou