2018-11-30 19:52:05 +00:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
2018-11-30 15:39:55 +00:00
|
|
|
/* vim: set ts=4 et sw=2 tw=80: */
|
2012-05-21 11:12:37 +00:00
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2015-05-19 18:15:34 +00:00
|
|
|
#include "mozilla/Logging.h"
|
2013-09-23 17:29:27 +00:00
|
|
|
#include "prtime.h"
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
#include "IMContextWrapper.h"
|
2016-03-16 04:47:49 +00:00
|
|
|
#include "nsGtkKeyUtils.h"
|
2010-03-19 04:21:16 +00:00
|
|
|
#include "nsWindow.h"
|
2015-03-17 07:07:02 +00:00
|
|
|
#include "mozilla/AutoRestore.h"
|
2012-10-26 13:32:10 +00:00
|
|
|
#include "mozilla/Likely.h"
|
2013-09-25 11:21:20 +00:00
|
|
|
#include "mozilla/MiscEvents.h"
|
2013-09-25 11:21:19 +00:00
|
|
|
#include "mozilla/Preferences.h"
|
2018-06-20 05:55:46 +00:00
|
|
|
#include "mozilla/Telemetry.h"
|
2016-03-16 04:47:49 +00:00
|
|
|
#include "mozilla/TextEventDispatcher.h"
|
2013-09-25 11:21:19 +00:00
|
|
|
#include "mozilla/TextEvents.h"
|
2015-06-11 10:50:15 +00:00
|
|
|
#include "WritingModes.h"
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
namespace mozilla {
|
|
|
|
namespace widget {
|
2011-05-27 08:15:20 +00:00
|
|
|
|
2016-06-22 07:31:37 +00:00
|
|
|
LazyLogModule gGtkIMLog("nsGtkIMModuleWidgets");
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
static inline const char* ToChar(bool aBool) {
|
|
|
|
return aBool ? "true" : "false";
|
2015-03-19 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
2012-08-22 15:56:38 +00:00
|
|
|
static const char* GetEnabledStateName(uint32_t aState) {
|
2010-03-19 04:21:16 +00:00
|
|
|
switch (aState) {
|
2011-11-27 11:51:53 +00:00
|
|
|
case IMEState::DISABLED:
|
2010-03-19 04:21:16 +00:00
|
|
|
return "DISABLED";
|
2011-11-27 11:51:53 +00:00
|
|
|
case IMEState::ENABLED:
|
2010-03-19 04:21:16 +00:00
|
|
|
return "ENABLED";
|
2011-11-27 11:51:53 +00:00
|
|
|
case IMEState::PASSWORD:
|
2010-03-19 04:21:16 +00:00
|
|
|
return "PASSWORD";
|
2011-11-27 11:51:53 +00:00
|
|
|
case IMEState::PLUGIN:
|
2010-03-19 04:21:16 +00:00
|
|
|
return "PLUG_IN";
|
|
|
|
default:
|
|
|
|
return "UNKNOWN ENABLED STATUS!!";
|
|
|
|
}
|
|
|
|
}
|
2015-03-19 16:52:24 +00:00
|
|
|
|
|
|
|
static const char* GetEventType(GdkEventKey* aKeyEvent) {
|
|
|
|
switch (aKeyEvent->type) {
|
|
|
|
case GDK_KEY_PRESS:
|
|
|
|
return "GDK_KEY_PRESS";
|
|
|
|
case GDK_KEY_RELEASE:
|
|
|
|
return "GDK_KEY_RELEASE";
|
|
|
|
default:
|
|
|
|
return "Unknown";
|
|
|
|
}
|
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
class GetEventStateName : public nsAutoCString {
|
|
|
|
public:
|
|
|
|
explicit GetEventStateName(guint aState,
|
|
|
|
IMContextWrapper::IMContextID aIMContextID =
|
|
|
|
IMContextWrapper::IMContextID::eUnknown) {
|
|
|
|
if (aState & GDK_SHIFT_MASK) {
|
|
|
|
AppendModifier("shift");
|
|
|
|
}
|
|
|
|
if (aState & GDK_CONTROL_MASK) {
|
|
|
|
AppendModifier("control");
|
|
|
|
}
|
|
|
|
if (aState & GDK_MOD1_MASK) {
|
|
|
|
AppendModifier("mod1");
|
|
|
|
}
|
|
|
|
if (aState & GDK_MOD2_MASK) {
|
|
|
|
AppendModifier("mod2");
|
|
|
|
}
|
|
|
|
if (aState & GDK_MOD3_MASK) {
|
|
|
|
AppendModifier("mod3");
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
if (aState & GDK_MOD4_MASK) {
|
|
|
|
AppendModifier("mod4");
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
if (aState & GDK_MOD4_MASK) {
|
|
|
|
AppendModifier("mod5");
|
|
|
|
}
|
|
|
|
if (aState & GDK_MOD4_MASK) {
|
|
|
|
AppendModifier("mod5");
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
switch (aIMContextID) {
|
|
|
|
case IMContextWrapper::IMContextID::eIBus:
|
|
|
|
static const guint IBUS_HANDLED_MASK = 1 << 24;
|
|
|
|
static const guint IBUS_IGNORED_MASK = 1 << 25;
|
|
|
|
if (aState & IBUS_HANDLED_MASK) {
|
|
|
|
AppendModifier("IBUS_HANDLED_MASK");
|
|
|
|
}
|
|
|
|
if (aState & IBUS_IGNORED_MASK) {
|
|
|
|
AppendModifier("IBUS_IGNORED_MASK");
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
case IMContextWrapper::IMContextID::eFcitx:
|
|
|
|
static const guint FcitxKeyState_HandledMask = 1 << 24;
|
|
|
|
static const guint FcitxKeyState_IgnoredMask = 1 << 25;
|
|
|
|
if (aState & FcitxKeyState_HandledMask) {
|
|
|
|
AppendModifier("FcitxKeyState_HandledMask");
|
|
|
|
}
|
|
|
|
if (aState & FcitxKeyState_IgnoredMask) {
|
|
|
|
AppendModifier("FcitxKeyState_IgnoredMask");
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
void AppendModifier(const char* aModifierName) {
|
|
|
|
if (!IsEmpty()) {
|
|
|
|
AppendLiteral(" + ");
|
|
|
|
}
|
|
|
|
Append(aModifierName);
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
};
|
|
|
|
|
2015-06-11 10:50:15 +00:00
|
|
|
class GetWritingModeName : public nsAutoCString {
|
|
|
|
public:
|
|
|
|
explicit GetWritingModeName(const WritingMode& aWritingMode) {
|
|
|
|
if (!aWritingMode.IsVertical()) {
|
|
|
|
AssignLiteral("Horizontal");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (aWritingMode.IsVerticalLR()) {
|
|
|
|
AssignLiteral("Vertical (LTR)");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
AssignLiteral("Vertical (RTL)");
|
|
|
|
}
|
|
|
|
virtual ~GetWritingModeName() {}
|
|
|
|
};
|
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
class GetTextRangeStyleText final : public nsAutoCString {
|
|
|
|
public:
|
|
|
|
explicit GetTextRangeStyleText(const TextRangeStyle& aStyle) {
|
|
|
|
if (!aStyle.IsDefined()) {
|
|
|
|
AssignLiteral("{ IsDefined()=false }");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (aStyle.IsLineStyleDefined()) {
|
|
|
|
AppendLiteral("{ mLineStyle=");
|
|
|
|
AppendLineStyle(aStyle.mLineStyle);
|
|
|
|
if (aStyle.IsUnderlineColorDefined()) {
|
|
|
|
AppendLiteral(", mUnderlineColor=");
|
|
|
|
AppendColor(aStyle.mUnderlineColor);
|
|
|
|
} else {
|
|
|
|
AppendLiteral(", IsUnderlineColorDefined=false");
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
|
|
|
} else {
|
2015-08-19 07:37:39 +00:00
|
|
|
AppendLiteral("{ IsLineStyleDefined()=false");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (aStyle.IsForegroundColorDefined()) {
|
|
|
|
AppendLiteral(", mForegroundColor=");
|
|
|
|
AppendColor(aStyle.mForegroundColor);
|
|
|
|
} else {
|
|
|
|
AppendLiteral(", IsForegroundColorDefined()=false");
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
if (aStyle.IsBackgroundColorDefined()) {
|
|
|
|
AppendLiteral(", mBackgroundColor=");
|
|
|
|
AppendColor(aStyle.mBackgroundColor);
|
|
|
|
} else {
|
|
|
|
AppendLiteral(", IsBackgroundColorDefined()=false");
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
AppendLiteral(" }");
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-08-19 07:37:39 +00:00
|
|
|
void AppendLineStyle(uint8_t aLineStyle) {
|
|
|
|
switch (aLineStyle) {
|
|
|
|
case TextRangeStyle::LINESTYLE_NONE:
|
|
|
|
AppendLiteral("LINESTYLE_NONE");
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
2015-08-19 07:37:39 +00:00
|
|
|
case TextRangeStyle::LINESTYLE_SOLID:
|
|
|
|
AppendLiteral("LINESTYLE_SOLID");
|
|
|
|
break;
|
|
|
|
case TextRangeStyle::LINESTYLE_DOTTED:
|
|
|
|
AppendLiteral("LINESTYLE_DOTTED");
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
2015-08-19 07:37:39 +00:00
|
|
|
case TextRangeStyle::LINESTYLE_DASHED:
|
|
|
|
AppendLiteral("LINESTYLE_DASHED");
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
2015-08-19 07:37:39 +00:00
|
|
|
case TextRangeStyle::LINESTYLE_DOUBLE:
|
|
|
|
AppendLiteral("LINESTYLE_DOUBLE");
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
2015-08-19 07:37:39 +00:00
|
|
|
case TextRangeStyle::LINESTYLE_WAVY:
|
|
|
|
AppendLiteral("LINESTYLE_WAVY");
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
|
|
|
default:
|
2015-08-19 07:37:39 +00:00
|
|
|
AppendPrintf("Invalid(0x%02X)", aLineStyle);
|
|
|
|
break;
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-08-19 07:37:39 +00:00
|
|
|
void AppendColor(nscolor aColor) {
|
|
|
|
AppendPrintf("{ R=0x%02X, G=0x%02X, B=0x%02X, A=0x%02X }", NS_GET_R(aColor),
|
|
|
|
NS_GET_G(aColor), NS_GET_B(aColor), NS_GET_A(aColor));
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-08-19 07:37:39 +00:00
|
|
|
virtual ~GetTextRangeStyleText(){};
|
|
|
|
};
|
|
|
|
|
2018-01-10 07:52:04 +00:00
|
|
|
const static bool kUseSimpleContextDefault = false;
|
2014-01-28 09:02:08 +00:00
|
|
|
|
2018-07-13 09:12:53 +00:00
|
|
|
/******************************************************************************
|
|
|
|
* SelectionStyleProvider
|
|
|
|
*
|
|
|
|
* IME (e.g., fcitx, ~4.2.8.3) may look up selection colors of widget, which
|
|
|
|
* is related to the window associated with the IM context, to support any
|
|
|
|
* colored widgets. Our editor (like <input type="text">) is rendered as
|
|
|
|
* native GtkTextView as far as possible by default and if editor color is
|
|
|
|
* changed by web apps, nsTextFrame may swap background color of foreground
|
|
|
|
* color of composition string for making composition string is always
|
|
|
|
* visually distinct in normal text.
|
|
|
|
*
|
|
|
|
* So, we would like IME to set style of composition string to good colors
|
|
|
|
* in GtkTextView. Therefore, this class overwrites selection colors of
|
|
|
|
* our widget with selection colors of GtkTextView so that it's possible IME
|
|
|
|
* to refer selection colors of GtkTextView via our widget.
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
class SelectionStyleProvider final {
|
|
|
|
public:
|
|
|
|
static SelectionStyleProvider* GetInstance() {
|
|
|
|
if (sHasShutDown) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
if (!sInstance) {
|
|
|
|
sInstance = new SelectionStyleProvider();
|
|
|
|
}
|
|
|
|
return sInstance;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2018-07-13 09:12:53 +00:00
|
|
|
|
|
|
|
static void Shutdown() {
|
|
|
|
if (sInstance) {
|
|
|
|
g_object_unref(sInstance->mProvider);
|
|
|
|
}
|
|
|
|
delete sInstance;
|
|
|
|
sInstance = nullptr;
|
|
|
|
sHasShutDown = true;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2018-07-13 09:12:53 +00:00
|
|
|
|
|
|
|
// aGDKWindow is a GTK window which will be associated with an IM context.
|
|
|
|
void AttachTo(GdkWindow* aGDKWindow) {
|
|
|
|
GtkWidget* widget = nullptr;
|
|
|
|
// gdk_window_get_user_data() typically returns pointer to widget that
|
|
|
|
// window belongs to. If it's widget, fcitx retrieves selection colors
|
|
|
|
// of them. So, we need to overwrite its style.
|
|
|
|
gdk_window_get_user_data(aGDKWindow, (gpointer*)&widget);
|
|
|
|
if (GTK_IS_WIDGET(widget)) {
|
|
|
|
gtk_style_context_add_provider(gtk_widget_get_style_context(widget),
|
|
|
|
GTK_STYLE_PROVIDER(mProvider),
|
|
|
|
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
|
|
|
|
2018-07-13 09:12:53 +00:00
|
|
|
void OnThemeChanged() {
|
|
|
|
// fcitx refers GtkStyle::text[GTK_STATE_SELECTED] and
|
|
|
|
// GtkStyle::bg[GTK_STATE_SELECTED] (although pair of text and *base*
|
|
|
|
// or *fg* and bg is correct). gtk_style_update_from_context() will
|
|
|
|
// set these colors using the widget's GtkStyleContext and so the
|
|
|
|
// colors can be controlled by a ":selected" CSS rule.
|
|
|
|
nsAutoCString style(":selected{");
|
|
|
|
// FYI: LookAndFeel always returns selection colors of GtkTextView.
|
|
|
|
nscolor selectionForegroundColor;
|
|
|
|
if (NS_SUCCEEDED(
|
|
|
|
LookAndFeel::GetColor(LookAndFeel::eColorID_TextSelectForeground,
|
|
|
|
&selectionForegroundColor))) {
|
|
|
|
double alpha =
|
|
|
|
static_cast<double>(NS_GET_A(selectionForegroundColor)) / 0xFF;
|
2019-01-07 14:43:31 +00:00
|
|
|
style.AppendPrintf("color:rgba(%u,%u,%u,",
|
2018-07-13 09:12:53 +00:00
|
|
|
NS_GET_R(selectionForegroundColor),
|
|
|
|
NS_GET_G(selectionForegroundColor),
|
2019-01-07 14:43:31 +00:00
|
|
|
NS_GET_B(selectionForegroundColor));
|
|
|
|
// We can't use AppendPrintf here, because it does locale-specific
|
|
|
|
// formatting of floating-point values.
|
|
|
|
style.AppendFloat(alpha);
|
|
|
|
style.AppendPrintf(");");
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2018-07-13 09:12:53 +00:00
|
|
|
nscolor selectionBackgroundColor;
|
|
|
|
if (NS_SUCCEEDED(
|
|
|
|
LookAndFeel::GetColor(LookAndFeel::eColorID_TextSelectBackground,
|
|
|
|
&selectionBackgroundColor))) {
|
|
|
|
double alpha =
|
|
|
|
static_cast<double>(NS_GET_A(selectionBackgroundColor)) / 0xFF;
|
2019-01-07 14:43:31 +00:00
|
|
|
style.AppendPrintf("background-color:rgba(%u,%u,%u,",
|
2018-07-13 09:12:53 +00:00
|
|
|
NS_GET_R(selectionBackgroundColor),
|
|
|
|
NS_GET_G(selectionBackgroundColor),
|
2019-01-07 14:43:31 +00:00
|
|
|
NS_GET_B(selectionBackgroundColor));
|
|
|
|
style.AppendFloat(alpha);
|
|
|
|
style.AppendPrintf(");");
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2018-07-13 09:12:53 +00:00
|
|
|
style.AppendLiteral("}");
|
|
|
|
gtk_css_provider_load_from_data(mProvider, style.get(), -1, nullptr);
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2018-07-13 09:12:53 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
static SelectionStyleProvider* sInstance;
|
|
|
|
static bool sHasShutDown;
|
|
|
|
GtkCssProvider* const mProvider;
|
|
|
|
|
|
|
|
SelectionStyleProvider() : mProvider(gtk_css_provider_new()) {
|
|
|
|
OnThemeChanged();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
SelectionStyleProvider* SelectionStyleProvider::sInstance = nullptr;
|
|
|
|
bool SelectionStyleProvider::sHasShutDown = false;
|
|
|
|
|
2015-06-11 10:50:15 +00:00
|
|
|
/******************************************************************************
|
2015-07-26 23:23:04 +00:00
|
|
|
* IMContextWrapper
|
2015-06-11 10:50:15 +00:00
|
|
|
******************************************************************************/
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
IMContextWrapper* IMContextWrapper::sLastFocusedContext = nullptr;
|
2018-12-28 07:02:05 +00:00
|
|
|
guint16 IMContextWrapper::sWaitingSynthesizedKeyPressHardwareKeyCode = 0;
|
2015-07-26 23:23:04 +00:00
|
|
|
bool IMContextWrapper::sUseSimpleContext;
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2016-03-16 04:47:49 +00:00
|
|
|
NS_IMPL_ISUPPORTS(IMContextWrapper, TextEventDispatcherListener,
|
|
|
|
nsISupportsWeakReference)
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
IMContextWrapper::IMContextWrapper(nsWindow* aOwnerWindow)
|
2014-09-26 00:05:13 +00:00
|
|
|
: mOwnerWindow(aOwnerWindow),
|
|
|
|
mLastFocusedWindow(nullptr),
|
|
|
|
mContext(nullptr),
|
|
|
|
mSimpleContext(nullptr),
|
|
|
|
mDummyContext(nullptr),
|
2014-11-10 09:07:44 +00:00
|
|
|
mComposingContext(nullptr),
|
2014-09-26 00:05:13 +00:00
|
|
|
mCompositionStart(UINT32_MAX),
|
|
|
|
mProcessingKeyEvent(nullptr),
|
|
|
|
mCompositionState(eCompositionState_NotComposing),
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
mIMContextID(IMContextID::eUnknown),
|
2014-09-26 00:05:13 +00:00
|
|
|
mIsIMFocused(false),
|
2018-02-22 11:56:08 +00:00
|
|
|
mFallbackToKeyEvent(false),
|
|
|
|
mKeyboardEventWasDispatched(false),
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
mKeyboardEventWasConsumed(false),
|
2015-03-17 07:07:02 +00:00
|
|
|
mIsDeletingSurrounding(false),
|
2015-06-11 10:50:15 +00:00
|
|
|
mLayoutChanged(false),
|
2015-06-26 07:08:29 +00:00
|
|
|
mSetCursorPositionOnKeyEvent(true),
|
2015-10-26 22:21:37 +00:00
|
|
|
mPendingResettingIMContext(false),
|
2016-09-15 13:36:23 +00:00
|
|
|
mRetrieveSurroundingSignalReceived(false),
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
mMaybeInDeadKeySequence(false),
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
mIsIMInAsyncKeyHandlingMode(false) {
|
2014-01-28 09:02:08 +00:00
|
|
|
static bool sFirstInstance = true;
|
|
|
|
if (sFirstInstance) {
|
|
|
|
sFirstInstance = false;
|
|
|
|
sUseSimpleContext =
|
|
|
|
Preferences::GetBool("intl.ime.use_simple_context_on_password_field",
|
|
|
|
kUseSimpleContextDefault);
|
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
Init();
|
|
|
|
}
|
|
|
|
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
static bool IsIBusInSyncMode() {
|
|
|
|
// See ibus_im_context_class_init() in client/gtk2/ibusimcontext.c
|
|
|
|
// https://github.com/ibus/ibus/blob/86963f2f94d1e4fc213b01c2bc2ba9dcf4b22219/client/gtk2/ibusimcontext.c#L610
|
|
|
|
const char* env = PR_GetEnv("IBUS_ENABLE_SYNC_MODE");
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
// See _get_boolean_env() in client/gtk2/ibusimcontext.c
|
|
|
|
// https://github.com/ibus/ibus/blob/86963f2f94d1e4fc213b01c2bc2ba9dcf4b22219/client/gtk2/ibusimcontext.c#L520-L537
|
|
|
|
if (!env) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
nsDependentCString envStr(env);
|
|
|
|
if (envStr.IsEmpty() || envStr.EqualsLiteral("0") ||
|
|
|
|
envStr.EqualsLiteral("false") || envStr.EqualsLiteral("False") ||
|
|
|
|
envStr.EqualsLiteral("FALSE")) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool GetFcitxBoolEnv(const char* aEnv) {
|
|
|
|
// See fcitx_utils_get_boolean_env in src/lib/fcitx-utils/utils.c
|
|
|
|
// https://github.com/fcitx/fcitx/blob/0c87840dc7d9460c2cb5feaeefec299d0d3d62ec/src/lib/fcitx-utils/utils.c#L721-L736
|
|
|
|
const char* env = PR_GetEnv(aEnv);
|
|
|
|
if (!env) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
nsDependentCString envStr(env);
|
|
|
|
if (envStr.IsEmpty() || envStr.EqualsLiteral("0") ||
|
|
|
|
envStr.EqualsLiteral("false")) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool IsFcitxInSyncMode() {
|
|
|
|
// See fcitx_im_context_class_init() in src/frontend/gtk2/fcitximcontext.c
|
|
|
|
// https://github.com/fcitx/fcitx/blob/78b98d9230dc9630e99d52e3172bdf440ffd08c4/src/frontend/gtk2/fcitximcontext.c#L395-L398
|
|
|
|
return GetFcitxBoolEnv("IBUS_ENABLE_SYNC_MODE") ||
|
|
|
|
GetFcitxBoolEnv("FCITX_ENABLE_SYNC_MODE");
|
|
|
|
}
|
|
|
|
|
2018-06-20 05:55:46 +00:00
|
|
|
nsDependentCSubstring IMContextWrapper::GetIMName() const {
|
|
|
|
const char* contextIDChar =
|
|
|
|
gtk_im_multicontext_get_context_id(GTK_IM_MULTICONTEXT(mContext));
|
|
|
|
if (!contextIDChar) {
|
|
|
|
return nsDependentCSubstring();
|
|
|
|
}
|
|
|
|
|
|
|
|
nsDependentCSubstring im(contextIDChar, strlen(contextIDChar));
|
|
|
|
|
|
|
|
// If the context is XIM, actual engine must be specified with
|
|
|
|
// |XMODIFIERS=@im=foo|.
|
|
|
|
const char* xmodifiersChar = PR_GetEnv("XMODIFIERS");
|
|
|
|
if (!im.EqualsLiteral("xim") || !xmodifiersChar) {
|
|
|
|
return im;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsDependentCString xmodifiers(xmodifiersChar);
|
|
|
|
int32_t atIMValueStart = xmodifiers.Find("@im=") + 4;
|
|
|
|
if (atIMValueStart < 4 ||
|
|
|
|
xmodifiers.Length() <= static_cast<size_t>(atIMValueStart)) {
|
|
|
|
return im;
|
|
|
|
}
|
|
|
|
|
|
|
|
int32_t atIMValueEnd = xmodifiers.Find("@", false, atIMValueStart);
|
|
|
|
if (atIMValueEnd > atIMValueStart) {
|
|
|
|
return nsDependentCSubstring(xmodifiersChar + atIMValueStart,
|
|
|
|
atIMValueEnd - atIMValueStart);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (atIMValueEnd == kNotFound) {
|
|
|
|
return nsDependentCSubstring(xmodifiersChar + atIMValueStart,
|
|
|
|
strlen(xmodifiersChar) - atIMValueStart);
|
|
|
|
}
|
|
|
|
|
|
|
|
return im;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::Init() {
|
2010-03-19 04:21:16 +00:00
|
|
|
MozContainer* container = mOwnerWindow->GetMozContainer();
|
2018-04-28 19:50:58 +00:00
|
|
|
MOZ_ASSERT(container, "container is null");
|
2012-09-14 01:56:59 +00:00
|
|
|
GdkWindow* gdkWindow = gtk_widget_get_window(GTK_WIDGET(container));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2018-07-13 09:12:53 +00:00
|
|
|
// Overwrite selection colors of the window before associating the window
|
|
|
|
// with IM context since IME may look up selection colors via IM context
|
|
|
|
// to support any colored widgets.
|
|
|
|
SelectionStyleProvider::GetInstance()->AttachTo(gdkWindow);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
// NOTE: gtk_im_*_new() abort (kill) the whole process when it fails.
|
|
|
|
// So, we don't need to check the result.
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
// Normal context.
|
|
|
|
mContext = gtk_im_multicontext_new();
|
|
|
|
gtk_im_context_set_client_window(mContext, gdkWindow);
|
|
|
|
g_signal_connect(mContext, "preedit_changed",
|
2015-07-26 23:23:04 +00:00
|
|
|
G_CALLBACK(IMContextWrapper::OnChangeCompositionCallback),
|
|
|
|
this);
|
2010-03-24 15:04:39 +00:00
|
|
|
g_signal_connect(mContext, "retrieve_surrounding",
|
2015-07-26 23:23:04 +00:00
|
|
|
G_CALLBACK(IMContextWrapper::OnRetrieveSurroundingCallback),
|
|
|
|
this);
|
2010-03-24 15:04:39 +00:00
|
|
|
g_signal_connect(mContext, "delete_surrounding",
|
2015-07-26 23:23:04 +00:00
|
|
|
G_CALLBACK(IMContextWrapper::OnDeleteSurroundingCallback),
|
|
|
|
this);
|
2010-03-19 04:21:16 +00:00
|
|
|
g_signal_connect(mContext, "commit",
|
2015-07-26 23:23:04 +00:00
|
|
|
G_CALLBACK(IMContextWrapper::OnCommitCompositionCallback),
|
|
|
|
this);
|
2010-03-19 04:21:16 +00:00
|
|
|
g_signal_connect(mContext, "preedit_start",
|
2015-07-26 23:23:04 +00:00
|
|
|
G_CALLBACK(IMContextWrapper::OnStartCompositionCallback),
|
|
|
|
this);
|
|
|
|
g_signal_connect(mContext, "preedit_end",
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
G_CALLBACK(IMContextWrapper::OnEndCompositionCallback),
|
|
|
|
this);
|
|
|
|
nsDependentCSubstring im = GetIMName();
|
2018-03-19 05:22:52 +00:00
|
|
|
if (im.EqualsLiteral("ibus")) {
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
mIMContextID = IMContextID::eIBus;
|
|
|
|
mIsIMInAsyncKeyHandlingMode = !IsIBusInSyncMode();
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
// Although ibus has key snooper mode, it's forcibly disabled on Firefox
|
|
|
|
// in default settings by its whitelist since we always send key events
|
|
|
|
// to IME before handling shortcut keys. The whitelist can be
|
|
|
|
// customized with env, IBUS_NO_SNOOPER_APPS, but we don't need to
|
|
|
|
// support such rare cases for reducing maintenance cost.
|
|
|
|
mIsKeySnooped = false;
|
2018-03-19 05:22:52 +00:00
|
|
|
} else if (im.EqualsLiteral("fcitx")) {
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
mIMContextID = IMContextID::eFcitx;
|
|
|
|
mIsIMInAsyncKeyHandlingMode = !IsFcitxInSyncMode();
|
|
|
|
// Although Fcitx has key snooper mode similar to ibus, it's also
|
|
|
|
// disabled on Firefox in default settings by its whitelist. The
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
// whitelist can be customized with env, IBUS_NO_SNOOPER_APPS or
|
|
|
|
// FCITX_NO_SNOOPER_APPS, but we don't need to support such rare cases
|
|
|
|
// for reducing maintenance cost.
|
|
|
|
mIsKeySnooped = false;
|
2018-03-19 05:22:52 +00:00
|
|
|
} else if (im.EqualsLiteral("uim")) {
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
mIMContextID = IMContextID::eUim;
|
|
|
|
mIsIMInAsyncKeyHandlingMode = false;
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
// We cannot know if uim uses key snooper since it's build option of
|
|
|
|
// uim. Therefore, we need to retrieve the consideration from the
|
|
|
|
// pref for making users and distributions allowed to choose their
|
|
|
|
// preferred value.
|
|
|
|
mIsKeySnooped =
|
2014-01-28 09:02:08 +00:00
|
|
|
Preferences::GetBool("intl.ime.hack.uim.using_key_snooper", true);
|
|
|
|
} else if (im.EqualsLiteral("scim")) {
|
|
|
|
mIMContextID = IMContextID::eScim;
|
|
|
|
mIsIMInAsyncKeyHandlingMode = false;
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
mIsKeySnooped = false;
|
2018-03-19 05:22:52 +00:00
|
|
|
} else if (im.EqualsLiteral("iiim")) {
|
2014-01-28 09:02:08 +00:00
|
|
|
mIMContextID = IMContextID::eIIIMF;
|
|
|
|
mIsIMInAsyncKeyHandlingMode = false;
|
2015-07-26 23:23:04 +00:00
|
|
|
mIsKeySnooped = false;
|
2018-11-30 10:46:48 +00:00
|
|
|
} else {
|
2015-07-26 23:23:04 +00:00
|
|
|
mIMContextID = IMContextID::eUnknown;
|
|
|
|
mIsIMInAsyncKeyHandlingMode = false;
|
2014-01-28 09:02:08 +00:00
|
|
|
mIsKeySnooped = false;
|
|
|
|
}
|
2013-10-29 09:04:59 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
// Simple context
|
2013-10-29 09:04:59 +00:00
|
|
|
if (sUseSimpleContext) {
|
2010-03-19 04:21:16 +00:00
|
|
|
mSimpleContext = gtk_im_context_simple_new();
|
|
|
|
gtk_im_context_set_client_window(mSimpleContext, gdkWindow);
|
2014-01-28 09:02:08 +00:00
|
|
|
g_signal_connect(mSimpleContext, "preedit_changed",
|
2015-07-26 23:23:04 +00:00
|
|
|
G_CALLBACK(&IMContextWrapper::OnChangeCompositionCallback),
|
2018-11-30 10:46:48 +00:00
|
|
|
this);
|
2010-03-19 04:21:16 +00:00
|
|
|
g_signal_connect(
|
2014-01-28 09:02:08 +00:00
|
|
|
mSimpleContext, "retrieve_surrounding",
|
2015-07-26 23:23:04 +00:00
|
|
|
G_CALLBACK(&IMContextWrapper::OnRetrieveSurroundingCallback), this);
|
2014-01-28 09:02:08 +00:00
|
|
|
g_signal_connect(mSimpleContext, "delete_surrounding",
|
2015-07-26 23:23:04 +00:00
|
|
|
G_CALLBACK(&IMContextWrapper::OnDeleteSurroundingCallback),
|
2018-11-30 10:46:48 +00:00
|
|
|
this);
|
2010-03-19 04:21:16 +00:00
|
|
|
g_signal_connect(mSimpleContext, "commit",
|
2015-07-26 23:23:04 +00:00
|
|
|
G_CALLBACK(&IMContextWrapper::OnCommitCompositionCallback),
|
2018-11-30 10:46:48 +00:00
|
|
|
this);
|
2014-01-28 09:02:08 +00:00
|
|
|
g_signal_connect(mSimpleContext, "preedit_start",
|
2015-07-26 23:23:04 +00:00
|
|
|
G_CALLBACK(IMContextWrapper::OnStartCompositionCallback),
|
2018-11-30 10:46:48 +00:00
|
|
|
this);
|
2014-01-28 09:02:08 +00:00
|
|
|
g_signal_connect(mSimpleContext, "preedit_end",
|
2015-07-26 23:23:04 +00:00
|
|
|
G_CALLBACK(IMContextWrapper::OnEndCompositionCallback),
|
2018-11-30 10:46:48 +00:00
|
|
|
this);
|
|
|
|
}
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
|
Bug 1282043 IMContextWrapper shouldn't append 0 length clause to TextRangeArray and if IME doesn't specify clause at beginning of the composition, it should insert dummy clause r=m_kato
Here is the patched build's log:
[Main Thread]: I/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(aContext=7fab5a7bbbf0, aCompositionString="÷" (Length()=1))
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to no attr, aTextRange= { mStartOffset=0, mEndOffset=1 }
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to current clause length is 0
[Main Thread]: E/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to g_utf8_to_utf16() failure (retrieving current clause)
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(), inserting a dummy clause at the beginning of the composition string mStartOffset=0, mEndOffset=1, mRangeType=TextRangeType::eRawClause
iBus Chewing IME has two clauses when user presses Shift+p, one doesn't have pango_attr, the other is empty. These clauses are not useful in Gecko. Additionally, TextRangeArray assumes that there is a clause at beginning of the composition when there is one or more clauses. Therefore, this patch tries to insert dummy clause at the beggining of composition in such case.
MozReview-Commit-ID: 3hVGVmvFrhA
--HG--
extra : rebase_source : edbd3a6a1139cffb0d5bfbe0c92bf6870c9a2608
2016-06-28 10:37:03 +00:00
|
|
|
// Dummy context
|
2012-07-30 14:20:58 +00:00
|
|
|
mDummyContext = gtk_im_multicontext_new();
|
|
|
|
gtk_im_context_set_client_window(mDummyContext, gdkWindow);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2018-03-19 05:22:52 +00:00
|
|
|
("0x%p Init(), mOwnerWindow=%p, mContext=%p (im=\"%s\"), "
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
"mIsIMInAsyncKeyHandlingMode=%s, mIsKeySnooped=%s, "
|
2018-06-20 05:55:46 +00:00
|
|
|
"mSimpleContext=%p, mDummyContext=%p, "
|
|
|
|
"gtk_im_multicontext_get_context_id()=\"%s\", "
|
|
|
|
"PR_GetEnv(\"XMODIFIERS\")=\"%s\"",
|
2018-03-19 05:22:52 +00:00
|
|
|
this, mOwnerWindow, mContext, nsAutoCString(im).get(),
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
ToChar(mIsIMInAsyncKeyHandlingMode), ToChar(mIsKeySnooped),
|
2018-06-20 05:55:46 +00:00
|
|
|
mSimpleContext, mDummyContext,
|
|
|
|
gtk_im_multicontext_get_context_id(GTK_IM_MULTICONTEXT(mContext)),
|
|
|
|
PR_GetEnv("XMODIFIERS")));
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2018-07-13 09:12:53 +00:00
|
|
|
/* static */
|
|
|
|
void IMContextWrapper::Shutdown() { SelectionStyleProvider::Shutdown(); }
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
IMContextWrapper::~IMContextWrapper() {
|
|
|
|
if (this == sLastFocusedContext) {
|
|
|
|
sLastFocusedContext = nullptr;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
2016-07-06 09:52:23 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info, ("0x%p ~IMContextWrapper()", this));
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2016-03-16 04:47:49 +00:00
|
|
|
NS_IMETHODIMP
|
|
|
|
IMContextWrapper::NotifyIME(TextEventDispatcher* aTextEventDispatcher,
|
|
|
|
const IMENotification& aNotification) {
|
|
|
|
switch (aNotification.mMessage) {
|
|
|
|
case REQUEST_TO_COMMIT_COMPOSITION:
|
|
|
|
case REQUEST_TO_CANCEL_COMPOSITION: {
|
|
|
|
nsWindow* window =
|
|
|
|
static_cast<nsWindow*>(aTextEventDispatcher->GetWidget());
|
|
|
|
return EndIMEComposition(window);
|
|
|
|
}
|
|
|
|
case NOTIFY_IME_OF_FOCUS:
|
|
|
|
OnFocusChangeInGecko(true);
|
|
|
|
return NS_OK;
|
|
|
|
case NOTIFY_IME_OF_BLUR:
|
|
|
|
OnFocusChangeInGecko(false);
|
|
|
|
return NS_OK;
|
|
|
|
case NOTIFY_IME_OF_POSITION_CHANGE:
|
|
|
|
OnLayoutChange();
|
|
|
|
return NS_OK;
|
2016-05-31 02:39:15 +00:00
|
|
|
case NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED:
|
2016-03-16 04:47:49 +00:00
|
|
|
OnUpdateComposition();
|
|
|
|
return NS_OK;
|
|
|
|
case NOTIFY_IME_OF_SELECTION_CHANGE: {
|
|
|
|
nsWindow* window =
|
|
|
|
static_cast<nsWindow*>(aTextEventDispatcher->GetWidget());
|
|
|
|
OnSelectionChange(window, aNotification);
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
return NS_ERROR_NOT_IMPLEMENTED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP_(void)
|
|
|
|
IMContextWrapper::OnRemovedFrom(TextEventDispatcher* aTextEventDispatcher) {
|
|
|
|
// XXX When input transaction is being stolen by add-on, what should we do?
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP_(void)
|
|
|
|
IMContextWrapper::WillDispatchKeyboardEvent(
|
|
|
|
TextEventDispatcher* aTextEventDispatcher,
|
|
|
|
WidgetKeyboardEvent& aKeyboardEvent, uint32_t aIndexOfKeypress,
|
|
|
|
void* aData) {
|
2016-03-16 04:47:49 +00:00
|
|
|
KeymapWrapper::WillDispatchKeyboardEvent(aKeyboardEvent,
|
|
|
|
static_cast<GdkEventKey*>(aData));
|
2016-03-16 04:47:49 +00:00
|
|
|
}
|
|
|
|
|
2016-03-16 04:47:49 +00:00
|
|
|
TextEventDispatcher* IMContextWrapper::GetTextEventDispatcher() {
|
|
|
|
if (NS_WARN_IF(!mLastFocusedWindow)) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
TextEventDispatcher* dispatcher =
|
|
|
|
mLastFocusedWindow->GetTextEventDispatcher();
|
|
|
|
// nsIWidget::GetTextEventDispatcher() shouldn't return nullptr.
|
|
|
|
MOZ_RELEASE_ASSERT(dispatcher);
|
|
|
|
return dispatcher;
|
|
|
|
}
|
|
|
|
|
2017-04-11 12:24:55 +00:00
|
|
|
NS_IMETHODIMP_(IMENotificationRequests)
|
|
|
|
IMContextWrapper::GetIMENotificationRequests() {
|
2015-10-10 01:21:02 +00:00
|
|
|
// While a plugin has focus, IMContextWrapper doesn't need any
|
|
|
|
// notifications.
|
|
|
|
if (mInputContext.mIMEState.mEnabled == IMEState::PLUGIN) {
|
2017-04-11 12:24:55 +00:00
|
|
|
return IMENotificationRequests();
|
2015-10-10 01:21:02 +00:00
|
|
|
}
|
|
|
|
|
2017-04-11 12:24:55 +00:00
|
|
|
IMENotificationRequests::Notifications notifications =
|
|
|
|
IMENotificationRequests::NOTIFY_NOTHING;
|
2015-08-06 06:57:58 +00:00
|
|
|
// If it's not enabled, we don't need position change notification.
|
|
|
|
if (IsEnabled()) {
|
2017-04-11 12:24:55 +00:00
|
|
|
notifications |= IMENotificationRequests::NOTIFY_POSITION_CHANGE;
|
2015-08-06 06:57:58 +00:00
|
|
|
}
|
2017-04-11 12:24:55 +00:00
|
|
|
return IMENotificationRequests(notifications);
|
2015-08-06 06:57:58 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnDestroyWindow(nsWindow* aWindow) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnDestroyWindow(aWindow=0x%p), mLastFocusedWindow=0x%p, "
|
|
|
|
"mOwnerWindow=0x%p, mLastFocusedModule=0x%p",
|
2015-07-26 23:23:04 +00:00
|
|
|
this, aWindow, mLastFocusedWindow, mOwnerWindow, sLastFocusedContext));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2018-04-28 19:50:58 +00:00
|
|
|
MOZ_ASSERT(aWindow, "aWindow must not be null");
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
if (mLastFocusedWindow == aWindow) {
|
2014-09-26 00:05:13 +00:00
|
|
|
EndIMEComposition(aWindow);
|
2010-03-19 04:21:16 +00:00
|
|
|
if (mIsIMFocused) {
|
|
|
|
Blur();
|
|
|
|
}
|
2012-07-30 14:20:58 +00:00
|
|
|
mLastFocusedWindow = nullptr;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
if (mOwnerWindow != aWindow) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
if (sLastFocusedContext == this) {
|
|
|
|
sLastFocusedContext = nullptr;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* NOTE:
|
|
|
|
* The given window is the owner of this, so, we must release the
|
|
|
|
* contexts now. But that might be referred from other nsWindows
|
|
|
|
* (they are children of this. But we don't know why there are the
|
|
|
|
* cases). So, we need to clear the pointers that refers to contexts
|
|
|
|
* and this if the other referrers are still alive. See bug 349727.
|
|
|
|
*/
|
|
|
|
if (mContext) {
|
|
|
|
PrepareToDestroyContext(mContext);
|
2012-07-30 14:20:58 +00:00
|
|
|
gtk_im_context_set_client_window(mContext, nullptr);
|
2011-05-11 13:10:36 +00:00
|
|
|
g_object_unref(mContext);
|
2012-07-30 14:20:58 +00:00
|
|
|
mContext = nullptr;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2013-10-29 09:04:59 +00:00
|
|
|
if (mSimpleContext) {
|
|
|
|
gtk_im_context_set_client_window(mSimpleContext, nullptr);
|
|
|
|
g_object_unref(mSimpleContext);
|
|
|
|
mSimpleContext = nullptr;
|
|
|
|
}
|
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
if (mDummyContext) {
|
|
|
|
// mContext and mDummyContext have the same slaveType and signal_data
|
|
|
|
// so no need for another workaround_gtk_im_display_closed.
|
2012-07-30 14:20:58 +00:00
|
|
|
gtk_im_context_set_client_window(mDummyContext, nullptr);
|
2011-05-11 13:10:36 +00:00
|
|
|
g_object_unref(mDummyContext);
|
2012-07-30 14:20:58 +00:00
|
|
|
mDummyContext = nullptr;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2014-11-10 09:07:44 +00:00
|
|
|
if (NS_WARN_IF(mComposingContext)) {
|
|
|
|
g_object_unref(mComposingContext);
|
|
|
|
mComposingContext = nullptr;
|
|
|
|
}
|
|
|
|
|
2012-07-30 14:20:58 +00:00
|
|
|
mOwnerWindow = nullptr;
|
|
|
|
mLastFocusedWindow = nullptr;
|
2011-11-27 11:51:53 +00:00
|
|
|
mInputContext.mIMEState.mEnabled = IMEState::DISABLED;
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
mPostingKeyEvents.Clear();
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnDestroyWindow(), succeeded, Completely destroyed", this));
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::PrepareToDestroyContext(GtkIMContext* aContext) {
|
2018-03-12 13:32:43 +00:00
|
|
|
if (mIMContextID == IMContextID::eIIIMF) {
|
|
|
|
// IIIM module registers handlers for the "closed" signal on the
|
|
|
|
// display, but the signal handler is not disconnected when the module
|
|
|
|
// is unloaded. To prevent the module from being unloaded, use static
|
|
|
|
// variable to hold reference of slave context class declared by IIIM.
|
|
|
|
// Note that this does not grab any instance, it grabs the "class".
|
|
|
|
static gpointer sGtkIIIMContextClass = nullptr;
|
|
|
|
if (!sGtkIIIMContextClass) {
|
|
|
|
// We retrieved slave context class with g_type_name() and actual
|
|
|
|
// slave context instance when our widget was GTK2. That must be
|
|
|
|
// _GtkIMContext::priv::slave in GTK3. However, _GtkIMContext::priv
|
|
|
|
// is an opacity struct named _GtkIMMulticontextPrivate, i.e., it's
|
|
|
|
// not exposed by GTK3. Therefore, we cannot access the instance
|
|
|
|
// safely. So, we need to retrieve the slave context class with
|
|
|
|
// g_type_from_name("GtkIMContextIIIM") directly (anyway, we needed
|
|
|
|
// to compare the class name with "GtkIMContextIIIM").
|
|
|
|
GType IIMContextType = g_type_from_name("GtkIMContextIIIM");
|
|
|
|
if (IIMContextType) {
|
|
|
|
sGtkIIIMContextClass = g_type_class_ref(IIMContextType);
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p PrepareToDestroyContext(), added to reference to "
|
|
|
|
"GtkIMContextIIIM class to prevent it from being unloaded",
|
|
|
|
this));
|
|
|
|
} else {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
|
|
|
("0x%p PrepareToDestroyContext(), FAILED to prevent the "
|
|
|
|
"IIIM module from being uploaded",
|
|
|
|
this));
|
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnFocusWindow(nsWindow* aWindow) {
|
2012-10-26 13:32:10 +00:00
|
|
|
if (MOZ_UNLIKELY(IsDestroyed())) {
|
2010-03-19 04:21:16 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnFocusWindow(aWindow=0x%p), mLastFocusedWindow=0x%p", this,
|
2011-08-03 22:36:00 +00:00
|
|
|
aWindow, mLastFocusedWindow));
|
2010-03-19 04:21:16 +00:00
|
|
|
mLastFocusedWindow = aWindow;
|
|
|
|
Focus();
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnBlurWindow(nsWindow* aWindow) {
|
2012-10-26 13:32:10 +00:00
|
|
|
if (MOZ_UNLIKELY(IsDestroyed())) {
|
2010-03-19 04:21:16 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnBlurWindow(aWindow=0x%p), mLastFocusedWindow=0x%p, "
|
2015-03-19 16:52:24 +00:00
|
|
|
"mIsIMFocused=%s",
|
2015-07-26 23:23:04 +00:00
|
|
|
this, aWindow, mLastFocusedWindow, ToChar(mIsIMFocused)));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
if (!mIsIMFocused || mLastFocusedWindow != aWindow) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
Blur();
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
KeyHandlingState IMContextWrapper::OnKeyEvent(
|
|
|
|
nsWindow* aCaller, GdkEventKey* aEvent,
|
2018-02-22 11:56:08 +00:00
|
|
|
bool aKeyboardEventWasDispatched /* = false */) {
|
2018-04-28 19:50:58 +00:00
|
|
|
MOZ_ASSERT(aEvent, "aEvent must be non-null");
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2014-11-10 09:07:43 +00:00
|
|
|
if (!mInputContext.mIMEState.MaybeEditable() || MOZ_UNLIKELY(IsDestroyed())) {
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
return KeyHandlingState::eNotHandled;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Info,
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
("0x%p OnKeyEvent(aCaller=0x%p, "
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
"aEvent(0x%p): { type=%s, keyval=%s, unicode=0x%X, state=%s, "
|
|
|
|
"time=%u, hardware_keycode=%u, group=%u }, "
|
|
|
|
"aKeyboardEventWasDispatched=%s)",
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
this, aCaller, aEvent, GetEventType(aEvent),
|
|
|
|
gdk_keyval_name(aEvent->keyval), gdk_keyval_to_unicode(aEvent->keyval),
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
GetEventStateName(aEvent->state, mIMContextID).get(), aEvent->time,
|
|
|
|
aEvent->hardware_keycode, aEvent->group,
|
|
|
|
ToChar(aKeyboardEventWasDispatched)));
|
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p OnKeyEvent(), mMaybeInDeadKeySequence=%s, "
|
|
|
|
"mCompositionState=%s, current context=%p, active context=%p, "
|
|
|
|
"mIMContextID=%s, mIsIMInAsyncKeyHandlingMode=%s",
|
|
|
|
this, ToChar(mMaybeInDeadKeySequence), GetCompositionStateName(),
|
|
|
|
GetCurrentContext(), GetActiveContext(),
|
|
|
|
GetIMContextIDName(mIMContextID), ToChar(mIsIMInAsyncKeyHandlingMode)));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
if (aCaller != mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnKeyEvent(), FAILED, the caller isn't focused "
|
|
|
|
"window, mLastFocusedWindow=0x%p",
|
2015-07-26 23:23:04 +00:00
|
|
|
this, mLastFocusedWindow));
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
return KeyHandlingState::eNotHandled;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-03-19 16:52:24 +00:00
|
|
|
// Even if old IM context has composition, key event should be sent to
|
|
|
|
// current context since the user expects so.
|
|
|
|
GtkIMContext* currentContext = GetCurrentContext();
|
|
|
|
if (MOZ_UNLIKELY(!currentContext)) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnKeyEvent(), FAILED, there are no context", this));
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
return KeyHandlingState::eNotHandled;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-06-26 07:08:29 +00:00
|
|
|
if (mSetCursorPositionOnKeyEvent) {
|
|
|
|
SetCursorPosition(currentContext);
|
|
|
|
mSetCursorPositionOnKeyEvent = false;
|
|
|
|
}
|
|
|
|
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
// Let's support dead key event even if active keyboard layout also
|
|
|
|
// supports complicated composition like CJK IME.
|
|
|
|
bool isDeadKey =
|
|
|
|
KeymapWrapper::ComputeDOMKeyNameIndex(aEvent) == KEY_NAME_INDEX_Dead;
|
|
|
|
mMaybeInDeadKeySequence |= isDeadKey;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
// If current context is mSimpleContext, both ibus and fcitx handles key
|
|
|
|
// events synchronously. So, only when current context is mContext which
|
|
|
|
// is GtkIMMulticontext, the key event may be handled by IME asynchronously.
|
Bug 1523635 - part 1: Rename `maybeHandledAsynchronously` to `probablyHandledAsynchronously` r=m_kato
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
2019-02-05 06:48:08 +00:00
|
|
|
bool probablyHandledAsynchronously =
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
mIsIMInAsyncKeyHandlingMode && currentContext == mContext;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2019-02-05 11:59:38 +00:00
|
|
|
// If we're not sure whether the event is handled asynchronously, this is
|
|
|
|
// set to true.
|
|
|
|
bool maybeHandledAsynchronously = false;
|
|
|
|
|
|
|
|
// If aEvent is a synthesized event for async handling, this will be set to
|
|
|
|
// true.
|
|
|
|
bool isHandlingAsyncEvent = false;
|
|
|
|
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
// If we've decided that the event won't be synthesized asyncrhonously
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
// by IME, but actually IME did it, this is set to true.
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
bool isUnexpectedAsyncEvent = false;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
// If IM is ibus or fcitx and it handles key events asynchronously,
|
|
|
|
// they mark aEvent->state as "handled by me" when they post key event
|
|
|
|
// to another process. Unfortunately, we need to check this hacky
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
// flag because it's difficult to store all pending key events by
|
|
|
|
// an array or a hashtable.
|
Bug 1523635 - part 1: Rename `maybeHandledAsynchronously` to `probablyHandledAsynchronously` r=m_kato
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
2019-02-05 06:48:08 +00:00
|
|
|
if (probablyHandledAsynchronously) {
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
switch (mIMContextID) {
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
case IMContextID::eIBus: {
|
|
|
|
// See src/ibustypes.h
|
|
|
|
static const guint IBUS_IGNORED_MASK = 1 << 25;
|
|
|
|
// If IBUS_IGNORED_MASK was set to aEvent->state, the event
|
|
|
|
// has already been handled by another process and it wasn't
|
|
|
|
// used by IME.
|
2019-02-05 11:59:38 +00:00
|
|
|
isHandlingAsyncEvent = !!(aEvent->state & IBUS_IGNORED_MASK);
|
2018-12-26 08:17:32 +00:00
|
|
|
if (!isHandlingAsyncEvent) {
|
|
|
|
// On some environments, IBUS_IGNORED_MASK flag is not set as
|
|
|
|
// expected. In such case, we keep pusing all events into the queue.
|
|
|
|
// I.e., that causes eating a lot of memory until it's blurred.
|
|
|
|
// Therefore, we need to check whether there is same timestamp event
|
|
|
|
// in the queue. This redundant cost should be low because in most
|
|
|
|
// causes, key events in the queue should be 2 or 4.
|
|
|
|
isHandlingAsyncEvent =
|
|
|
|
mPostingKeyEvents.IndexOf(aEvent) != GdkEventKeyQueue::NoIndex();
|
|
|
|
if (isHandlingAsyncEvent) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p OnKeyEvent(), aEvent->state does not have "
|
|
|
|
"IBUS_IGNORED_MASK but "
|
|
|
|
"same event in the queue. So, assuming it's a "
|
|
|
|
"synthesized event",
|
|
|
|
this));
|
|
|
|
}
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2019-02-05 11:59:38 +00:00
|
|
|
// If it's a synthesized event, let's remove it from the posting
|
|
|
|
// event queue first. Otherwise the following blocks cannot use
|
|
|
|
// `break`.
|
|
|
|
if (isHandlingAsyncEvent) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p OnKeyEvent(), aEvent->state has IBUS_IGNORED_MASK "
|
|
|
|
"or aEvent is in the "
|
|
|
|
"posting event queue, so, it won't be handled "
|
|
|
|
"asynchronously anymore. Removing "
|
|
|
|
"the posted events from the queue",
|
|
|
|
this));
|
|
|
|
probablyHandledAsynchronously = false;
|
|
|
|
mPostingKeyEvents.RemoveEvent(aEvent);
|
|
|
|
}
|
|
|
|
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
// ibus won't send back key press events in a dead key sequcne.
|
|
|
|
if (mMaybeInDeadKeySequence && aEvent->type == GDK_KEY_PRESS) {
|
Bug 1523635 - part 1: Rename `maybeHandledAsynchronously` to `probablyHandledAsynchronously` r=m_kato
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
2019-02-05 06:48:08 +00:00
|
|
|
probablyHandledAsynchronously = false;
|
Bug 1511752 - Make IMContextWrapper::OnKeyEvent() treat GDK_KEY_PRESS event without any key information in a dead key sequence as synthesized by current keyboard layout for asynchronous handling r=m_kato
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
2018-12-03 15:15:13 +00:00
|
|
|
if (isHandlingAsyncEvent) {
|
|
|
|
isUnexpectedAsyncEvent = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
// Some keyboard layouts which have dead keys may send
|
|
|
|
// "empty" key event to make us call
|
|
|
|
// gtk_im_context_filter_keypress() to commit composed
|
|
|
|
// character during a GDK_KEY_PRESS event dispatching.
|
|
|
|
if (!gdk_keyval_to_unicode(aEvent->keyval) &&
|
|
|
|
!aEvent->hardware_keycode) {
|
|
|
|
isUnexpectedAsyncEvent = true;
|
|
|
|
break;
|
|
|
|
}
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
break;
|
|
|
|
}
|
2019-02-05 11:59:38 +00:00
|
|
|
// ibus may handle key events synchronously if focused editor is
|
|
|
|
// <input type="password"> or |ime-mode: disabled;|. However, in
|
|
|
|
// some environments, not so actually. Therefore, we need to check
|
|
|
|
// the result of gtk_im_context_filter_keypress() later.
|
|
|
|
if (mInputContext.mIMEState.mEnabled == IMEState::PASSWORD) {
|
Bug 1523635 - part 1: Rename `maybeHandledAsynchronously` to `probablyHandledAsynchronously` r=m_kato
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
2019-02-05 06:48:08 +00:00
|
|
|
probablyHandledAsynchronously = false;
|
2019-02-05 11:59:38 +00:00
|
|
|
maybeHandledAsynchronously = !isHandlingAsyncEvent;
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
break;
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
|
|
|
}
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
case IMContextID::eFcitx: {
|
|
|
|
// See src/lib/fcitx-utils/keysym.h
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
static const guint FcitxKeyState_IgnoredMask = 1 << 25;
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
// If FcitxKeyState_IgnoredMask was set to aEvent->state,
|
|
|
|
// the event has already been handled by another process and
|
|
|
|
// it wasn't used by IME.
|
2019-02-05 11:59:38 +00:00
|
|
|
isHandlingAsyncEvent = !!(aEvent->state & FcitxKeyState_IgnoredMask);
|
2018-12-26 08:17:32 +00:00
|
|
|
if (!isHandlingAsyncEvent) {
|
|
|
|
// On some environments, FcitxKeyState_IgnoredMask flag *might* be not
|
|
|
|
// set as expected. If there were such cases, we'd keep pusing all
|
|
|
|
// events into the queue. I.e., that would cause eating a lot of
|
|
|
|
// memory until it'd be blurred. Therefore, we should check whether
|
|
|
|
// there is same timestamp event in the queue. This redundant cost
|
|
|
|
// should be low because in most causes, key events in the queue
|
|
|
|
// should be 2 or 4.
|
|
|
|
isHandlingAsyncEvent =
|
|
|
|
mPostingKeyEvents.IndexOf(aEvent) != GdkEventKeyQueue::NoIndex();
|
|
|
|
if (isHandlingAsyncEvent) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p OnKeyEvent(), aEvent->state does not have "
|
|
|
|
"FcitxKeyState_IgnoredMask "
|
|
|
|
"but same event in the queue. So, assuming it's a "
|
|
|
|
"synthesized event",
|
|
|
|
this));
|
|
|
|
}
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
// fcitx won't send back key press events in a dead key sequcne.
|
|
|
|
if (mMaybeInDeadKeySequence && aEvent->type == GDK_KEY_PRESS) {
|
Bug 1523635 - part 1: Rename `maybeHandledAsynchronously` to `probablyHandledAsynchronously` r=m_kato
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
2019-02-05 06:48:08 +00:00
|
|
|
probablyHandledAsynchronously = false;
|
Bug 1511752 - Make IMContextWrapper::OnKeyEvent() treat GDK_KEY_PRESS event without any key information in a dead key sequence as synthesized by current keyboard layout for asynchronous handling r=m_kato
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
2018-12-03 15:15:13 +00:00
|
|
|
if (isHandlingAsyncEvent) {
|
|
|
|
isUnexpectedAsyncEvent = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
// Some keyboard layouts which have dead keys may send
|
|
|
|
// "empty" key event to make us call
|
|
|
|
// gtk_im_context_filter_keypress() to commit composed
|
|
|
|
// character during a GDK_KEY_PRESS event dispatching.
|
|
|
|
if (!gdk_keyval_to_unicode(aEvent->keyval) &&
|
|
|
|
!aEvent->hardware_keycode) {
|
|
|
|
isUnexpectedAsyncEvent = true;
|
|
|
|
break;
|
|
|
|
}
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
// fcitx handles key events asynchronously even if focused
|
|
|
|
// editor cannot use IME actually.
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
if (isHandlingAsyncEvent) {
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p OnKeyEvent(), aEvent->state has "
|
2018-12-26 08:17:32 +00:00
|
|
|
"FcitxKeyState_IgnoredMask or aEvent is in "
|
|
|
|
"the posting event queue, so, it won't be handled "
|
|
|
|
"asynchronously anymore. "
|
|
|
|
"Removing the posted events from the queue",
|
2018-11-30 10:46:48 +00:00
|
|
|
this));
|
Bug 1523635 - part 1: Rename `maybeHandledAsynchronously` to `probablyHandledAsynchronously` r=m_kato
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
2019-02-05 06:48:08 +00:00
|
|
|
probablyHandledAsynchronously = false;
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
mPostingKeyEvents.RemoveEvent(aEvent);
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
MOZ_ASSERT_UNREACHABLE(
|
2018-02-22 11:56:08 +00:00
|
|
|
"IME may handle key event "
|
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
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
2018-03-08 15:46:52 +00:00
|
|
|
"asyncrhonously, but not yet confirmed if it comes agian "
|
|
|
|
"actually");
|
2011-03-25 01:08:00 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2011-03-25 01:08:00 +00:00
|
|
|
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
if (!isUnexpectedAsyncEvent) {
|
|
|
|
mKeyboardEventWasDispatched = aKeyboardEventWasDispatched;
|
|
|
|
mKeyboardEventWasConsumed = false;
|
2018-11-30 10:46:48 +00:00
|
|
|
} else {
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
// If we didn't expect this event, we've alreday dispatched eKeyDown
|
|
|
|
// event or eKeyUp event for that.
|
|
|
|
mKeyboardEventWasDispatched = true;
|
|
|
|
// And in this case, we need to assume that another key event hasn't
|
|
|
|
// been receivied and mKeyboardEventWasConsumed keeps storing the
|
|
|
|
// dispatched eKeyDown or eKeyUp event's state.
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2018-02-22 11:56:08 +00:00
|
|
|
mFallbackToKeyEvent = false;
|
2010-03-19 04:21:16 +00:00
|
|
|
mProcessingKeyEvent = aEvent;
|
2015-03-19 16:52:24 +00:00
|
|
|
gboolean isFiltered = gtk_im_context_filter_keypress(currentContext, aEvent);
|
2019-02-05 11:59:38 +00:00
|
|
|
|
|
|
|
// If we're not sure whether the event is handled by IME asynchronously or
|
|
|
|
// synchronously, we need to trust the result of
|
|
|
|
// gtk_im_context_filter_keypress(). If it consumed and but did nothing,
|
|
|
|
// we can assume that another event will be synthesized.
|
|
|
|
if (!isHandlingAsyncEvent && maybeHandledAsynchronously) {
|
|
|
|
probablyHandledAsynchronously |=
|
|
|
|
isFiltered && !mFallbackToKeyEvent && !mKeyboardEventWasDispatched;
|
|
|
|
}
|
|
|
|
|
2018-12-28 07:02:05 +00:00
|
|
|
if (aEvent->type == GDK_KEY_PRESS) {
|
Bug 1523635 - part 1: Rename `maybeHandledAsynchronously` to `probablyHandledAsynchronously` r=m_kato
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
2019-02-05 06:48:08 +00:00
|
|
|
if (isFiltered && probablyHandledAsynchronously) {
|
2018-12-28 07:02:05 +00:00
|
|
|
sWaitingSynthesizedKeyPressHardwareKeyCode = aEvent->hardware_keycode;
|
|
|
|
} else {
|
|
|
|
sWaitingSynthesizedKeyPressHardwareKeyCode = 0;
|
|
|
|
}
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2018-02-22 11:56:08 +00:00
|
|
|
// The caller of this shouldn't handle aEvent anymore if we've dispatched
|
|
|
|
// composition events or modified content with other events.
|
|
|
|
bool filterThisEvent = isFiltered && !mFallbackToKeyEvent;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2018-02-22 11:56:08 +00:00
|
|
|
if (IsComposingOnCurrentContext() && !isFiltered &&
|
|
|
|
aEvent->type == GDK_KEY_PRESS && mDispatchedCompositionString.IsEmpty()) {
|
|
|
|
// A Hangul input engine for SCIM doesn't emit preedit_end
|
|
|
|
// signal even when composition string becomes empty. On the
|
|
|
|
// other hand, we should allow to make composition with empty
|
|
|
|
// string for other languages because there *might* be such
|
|
|
|
// IM. For compromising this issue, we should dispatch
|
|
|
|
// compositionend event, however, we don't need to reset IM
|
|
|
|
// actually.
|
|
|
|
// NOTE: Don't dispatch key events as "processed by IME" since
|
|
|
|
// we need to dispatch keyboard events as IME wasn't handled it.
|
|
|
|
mProcessingKeyEvent = nullptr;
|
|
|
|
DispatchCompositionCommitEvent(currentContext, &EmptyString());
|
2010-03-19 04:21:16 +00:00
|
|
|
mProcessingKeyEvent = aEvent;
|
2018-02-22 11:56:08 +00:00
|
|
|
// In this case, even though we handle the keyboard event here,
|
|
|
|
// but we should dispatch keydown event as
|
|
|
|
filterThisEvent = false;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2018-02-22 11:56:08 +00:00
|
|
|
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
if (filterThisEvent && !mKeyboardEventWasDispatched) {
|
|
|
|
// If IME handled the key event but we've not dispatched eKeyDown nor
|
|
|
|
// eKeyUp event yet, we need to dispatch here unless the key event is
|
|
|
|
// now being handled by other IME process.
|
Bug 1523635 - part 1: Rename `maybeHandledAsynchronously` to `probablyHandledAsynchronously` r=m_kato
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
2019-02-05 06:48:08 +00:00
|
|
|
if (!probablyHandledAsynchronously) {
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
MaybeDispatchKeyEventAsProcessedByIME(eVoidEvent);
|
|
|
|
// Be aware, the widget might have been gone here.
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
// If we need to wait reply from IM, IM may send some signals to us
|
|
|
|
// without sending the key event again. In such case, we need to
|
|
|
|
// dispatch keyboard events with a copy of aEvent. Therefore, we
|
|
|
|
// need to use information of this key event to dispatch an KeyDown
|
|
|
|
// or eKeyUp event later.
|
|
|
|
else {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p OnKeyEvent(), putting aEvent into the queue...", this));
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
mPostingKeyEvents.PutEvent(aEvent);
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
mProcessingKeyEvent = nullptr;
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
if (aEvent->type == GDK_KEY_PRESS && !filterThisEvent) {
|
|
|
|
// If the key event hasn't been handled by active IME nor keyboard
|
2016-07-06 09:52:23 +00:00
|
|
|
// layout, we can assume that the dead key sequence has been or was
|
2015-07-26 23:23:04 +00:00
|
|
|
// ended. Note that we should not reset it when the key event is
|
|
|
|
// GDK_KEY_RELEASE since it may not be filtered by active keyboard
|
|
|
|
// layout even in composition.
|
|
|
|
mMaybeInDeadKeySequence = false;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2012-03-09 04:27:51 +00:00
|
|
|
|
2019-02-05 11:59:38 +00:00
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Debug,
|
|
|
|
("0x%p OnKeyEvent(), succeeded, filterThisEvent=%s "
|
|
|
|
"(isFiltered=%s, mFallbackToKeyEvent=%s, "
|
|
|
|
"probablyHandledAsynchronously=%s, maybeHandledAsynchronously=%s), "
|
|
|
|
"mPostingKeyEvents.Length()=%zu, mCompositionState=%s, "
|
|
|
|
"mMaybeInDeadKeySequence=%s, mKeyboardEventWasDispatched=%s, "
|
|
|
|
"mKeyboardEventWasConsumed=%s",
|
|
|
|
this, ToChar(filterThisEvent), ToChar(isFiltered),
|
|
|
|
ToChar(mFallbackToKeyEvent), ToChar(probablyHandledAsynchronously),
|
|
|
|
ToChar(maybeHandledAsynchronously), mPostingKeyEvents.Length(),
|
|
|
|
GetCompositionStateName(), ToChar(mMaybeInDeadKeySequence),
|
|
|
|
ToChar(mKeyboardEventWasDispatched), ToChar(mKeyboardEventWasConsumed)));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
if (filterThisEvent) {
|
2012-03-09 04:27:51 +00:00
|
|
|
return KeyHandlingState::eHandled;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2012-03-09 04:27:51 +00:00
|
|
|
// If another call of this method has already dispatched eKeyDown event,
|
|
|
|
// we should return KeyHandlingState::eNotHandledButEventDispatched because
|
|
|
|
// the caller should've stopped handling the event if preceding eKeyDown
|
2017-06-27 09:46:08 +00:00
|
|
|
// event was consumed.
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
if (aKeyboardEventWasDispatched) {
|
2017-06-27 09:46:08 +00:00
|
|
|
return KeyHandlingState::eNotHandledButEventDispatched;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
if (!mKeyboardEventWasDispatched) {
|
2015-06-11 10:50:15 +00:00
|
|
|
return KeyHandlingState::eNotHandled;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-06-11 10:50:15 +00:00
|
|
|
return mKeyboardEventWasConsumed
|
|
|
|
? KeyHandlingState::eNotHandledButEventConsumed
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
: KeyHandlingState::eNotHandledButEventDispatched;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnFocusChangeInGecko(bool aFocus) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnFocusChangeInGecko(aFocus=%s), "
|
|
|
|
"mCompositionState=%s, mIsIMFocused=%s",
|
2015-07-26 23:23:04 +00:00
|
|
|
this, ToChar(aFocus), GetCompositionStateName(), ToChar(mIsIMFocused)));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2014-11-10 09:07:44 +00:00
|
|
|
// We shouldn't carry over the removed string to another editor.
|
|
|
|
mSelectedStringRemovedByComposition.Truncate();
|
|
|
|
mSelection.Clear();
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
|
|
|
|
2014-11-10 09:07:44 +00:00
|
|
|
void IMContextWrapper::ResetIME() {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p ResetIME(), mCompositionState=%s, mIsIMFocused=%s", this,
|
2015-07-26 23:23:04 +00:00
|
|
|
GetCompositionStateName(), ToChar(mIsIMFocused)));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2015-10-18 05:24:48 +00:00
|
|
|
GtkIMContext* activeContext = GetActiveContext();
|
|
|
|
if (MOZ_UNLIKELY(!activeContext)) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2015-10-18 05:24:48 +00:00
|
|
|
("0x%p ResetIME(), FAILED, there are no context", this));
|
|
|
|
return;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-03-19 16:52:25 +00:00
|
|
|
|
2015-10-26 22:21:37 +00:00
|
|
|
RefPtr<IMContextWrapper> kungFuDeathGrip(this);
|
|
|
|
RefPtr<nsWindow> lastFocusedWindow(mLastFocusedWindow);
|
2015-03-19 16:52:25 +00:00
|
|
|
|
|
|
|
mPendingResettingIMContext = false;
|
|
|
|
gtk_im_context_reset(activeContext);
|
|
|
|
|
|
|
|
// The last focused window might have been destroyed by a DOM event handler
|
|
|
|
// which was called by us during a call of gtk_im_context_reset().
|
|
|
|
if (!lastFocusedWindow ||
|
|
|
|
NS_WARN_IF(lastFocusedWindow != mLastFocusedWindow) ||
|
|
|
|
lastFocusedWindow->Destroyed()) {
|
|
|
|
return;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-03-19 16:52:25 +00:00
|
|
|
|
|
|
|
nsAutoString compositionString;
|
2014-10-23 17:17:15 +00:00
|
|
|
GetCompositionString(activeContext, compositionString);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p ResetIME() called gtk_im_context_reset(), "
|
|
|
|
"activeContext=0x%p, mCompositionState=%s, compositionString=%s, "
|
2015-03-19 16:52:25 +00:00
|
|
|
"mIsIMFocused=%s",
|
|
|
|
this, activeContext, GetCompositionStateName(),
|
|
|
|
NS_ConvertUTF16toUTF8(compositionString).get(), ToChar(mIsIMFocused)));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-03-19 16:52:25 +00:00
|
|
|
// XXX IIIMF (ATOK X3 which is one of the Language Engine of it is still
|
|
|
|
// used in Japan!) sends only "preedit_changed" signal with empty
|
|
|
|
// composition string synchronously. Therefore, if composition string
|
|
|
|
// is now empty string, we should assume that the IME won't send
|
|
|
|
// "commit" signal.
|
|
|
|
if (IsComposing() && compositionString.IsEmpty()) {
|
|
|
|
// WARNING: The widget might have been gone after this.
|
|
|
|
DispatchCompositionCommitEvent(activeContext, &EmptyString());
|
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
nsresult IMContextWrapper::EndIMEComposition(nsWindow* aCaller) {
|
2012-10-26 13:32:10 +00:00
|
|
|
if (MOZ_UNLIKELY(IsDestroyed())) {
|
2010-03-19 04:21:16 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p EndIMEComposition(aCaller=0x%p), "
|
2013-03-06 06:14:34 +00:00
|
|
|
"mCompositionState=%s",
|
2012-03-09 04:27:51 +00:00
|
|
|
this, aCaller, GetCompositionStateName()));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
if (aCaller != mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p EndIMEComposition(), FAILED, the caller isn't "
|
|
|
|
"focused window, mLastFocusedWindow=0x%p",
|
2015-07-26 23:23:04 +00:00
|
|
|
this, mLastFocusedWindow));
|
2010-03-19 04:21:16 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2012-03-09 04:27:51 +00:00
|
|
|
if (!IsComposing()) {
|
2010-03-19 04:21:16 +00:00
|
|
|
return NS_OK;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
|
|
|
|
2014-09-26 00:05:13 +00:00
|
|
|
// Currently, GTK has API neither to commit nor to cancel composition
|
|
|
|
// forcibly. Therefore, TextComposition will recompute commit string for
|
|
|
|
// the request even if native IME will cause unexpected commit string.
|
|
|
|
// So, we don't need to emulate commit or cancel composition with
|
2014-10-07 10:01:47 +00:00
|
|
|
// proper composition events.
|
2014-09-26 00:05:13 +00:00
|
|
|
// XXX ResetIME() might not enough for finishing compositoin on some
|
|
|
|
// environments. We should emulate focus change too because some IMEs
|
|
|
|
// may commit or cancel composition at blur.
|
2010-03-19 04:21:16 +00:00
|
|
|
ResetIME();
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnLayoutChange() {
|
2014-01-16 10:04:48 +00:00
|
|
|
if (MOZ_UNLIKELY(IsDestroyed())) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-06-26 07:08:29 +00:00
|
|
|
if (IsComposing()) {
|
|
|
|
SetCursorPosition(GetActiveContext());
|
|
|
|
} else {
|
|
|
|
// If not composing, candidate window position is updated before key
|
|
|
|
// down
|
|
|
|
mSetCursorPositionOnKeyEvent = true;
|
|
|
|
}
|
2015-06-11 10:50:15 +00:00
|
|
|
mLayoutChanged = true;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnUpdateComposition() {
|
2015-06-11 10:50:15 +00:00
|
|
|
if (MOZ_UNLIKELY(IsDestroyed())) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-06-15 07:01:39 +00:00
|
|
|
if (!IsComposing()) {
|
|
|
|
// Composition has been committed. So we need update selection for
|
2015-06-26 07:08:29 +00:00
|
|
|
// caret later
|
2015-06-15 07:01:39 +00:00
|
|
|
mSelection.Clear();
|
|
|
|
EnsureToCacheSelection();
|
2015-06-26 07:08:29 +00:00
|
|
|
mSetCursorPositionOnKeyEvent = true;
|
2015-06-15 07:01:39 +00:00
|
|
|
}
|
|
|
|
|
2015-06-11 10:50:15 +00:00
|
|
|
// If we've already set candidate window position, we don't need to update
|
|
|
|
// the position with update composition notification.
|
|
|
|
if (!mLayoutChanged) {
|
|
|
|
SetCursorPosition(GetActiveContext());
|
|
|
|
}
|
2014-01-16 10:04:48 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::SetInputContext(nsWindow* aCaller,
|
|
|
|
const InputContext* aContext,
|
|
|
|
const InputContextAction* aAction) {
|
2012-10-26 13:32:10 +00:00
|
|
|
if (MOZ_UNLIKELY(IsDestroyed())) {
|
2011-11-27 11:51:52 +00:00
|
|
|
return;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetInputContext(aCaller=0x%p, aContext={ mIMEState={ "
|
2015-07-26 23:23:04 +00:00
|
|
|
"mEnabled=%s }, mHTMLInputType=%s })",
|
2011-11-27 11:51:53 +00:00
|
|
|
this, aCaller, GetEnabledStateName(aContext->mIMEState.mEnabled),
|
2011-08-03 22:36:00 +00:00
|
|
|
NS_ConvertUTF16toUTF8(aContext->mHTMLInputType).get()));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
if (aCaller != mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetInputContext(), FAILED, "
|
|
|
|
"the caller isn't focused window, mLastFocusedWindow=0x%p",
|
2015-07-26 23:23:04 +00:00
|
|
|
this, mLastFocusedWindow));
|
2011-11-27 11:51:52 +00:00
|
|
|
return;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!mContext) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetInputContext(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"there are no context",
|
|
|
|
this));
|
2011-11-27 11:51:52 +00:00
|
|
|
return;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
if (sLastFocusedContext != this) {
|
2011-11-27 11:51:52 +00:00
|
|
|
mInputContext = *aContext;
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetInputContext(), succeeded, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"but we're not active",
|
|
|
|
this));
|
2011-11-27 11:51:52 +00:00
|
|
|
return;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2011-11-27 11:51:53 +00:00
|
|
|
bool changingEnabledState =
|
2014-01-28 09:02:08 +00:00
|
|
|
aContext->mIMEState.mEnabled != mInputContext.mIMEState.mEnabled ||
|
|
|
|
aContext->mHTMLInputType != mInputContext.mHTMLInputType;
|
2011-11-27 11:51:53 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
// Release current IME focus if IME is enabled.
|
2014-11-10 09:07:43 +00:00
|
|
|
if (changingEnabledState && mInputContext.mIMEState.MaybeEditable()) {
|
2014-09-26 00:05:13 +00:00
|
|
|
EndIMEComposition(mLastFocusedWindow);
|
2010-03-19 04:21:16 +00:00
|
|
|
Blur();
|
|
|
|
}
|
|
|
|
|
2011-11-27 11:51:52 +00:00
|
|
|
mInputContext = *aContext;
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2011-11-27 11:51:53 +00:00
|
|
|
if (changingEnabledState) {
|
2018-01-09 10:51:07 +00:00
|
|
|
#ifdef MOZ_WIDGET_GTK
|
2014-01-28 09:02:08 +00:00
|
|
|
static bool sInputPurposeSupported = !gtk_check_version(3, 6, 0);
|
2014-11-10 09:07:43 +00:00
|
|
|
if (sInputPurposeSupported && mInputContext.mIMEState.MaybeEditable()) {
|
2014-11-10 09:07:44 +00:00
|
|
|
GtkIMContext* currentContext = GetCurrentContext();
|
|
|
|
if (currentContext) {
|
2014-01-28 09:02:08 +00:00
|
|
|
GtkInputPurpose purpose = GTK_INPUT_PURPOSE_FREE_FORM;
|
|
|
|
const nsString& inputType = mInputContext.mHTMLInputType;
|
2014-01-28 09:02:08 +00:00
|
|
|
// Password case has difficult issue. Desktop IMEs disable
|
|
|
|
// composition if input-purpose is password.
|
|
|
|
// For disabling IME on |ime-mode: disabled;|, we need to check
|
|
|
|
// mEnabled value instead of inputType value. This hack also
|
|
|
|
// enables composition on
|
|
|
|
// <input type="password" style="ime-mode: enabled;">.
|
|
|
|
// This is right behavior of ime-mode on desktop.
|
|
|
|
//
|
|
|
|
// On the other hand, IME for tablet devices may provide a
|
|
|
|
// specific software keyboard for password field. If so,
|
|
|
|
// the behavior might look strange on both:
|
|
|
|
// <input type="text" style="ime-mode: disabled;">
|
|
|
|
// <input type="password" style="ime-mode: enabled;">
|
|
|
|
//
|
|
|
|
// Temporarily, we should focus on desktop environment for now.
|
|
|
|
// I.e., let's ignore tablet devices for now. When somebody
|
|
|
|
// reports actual trouble on tablet devices, we should try to
|
|
|
|
// look for a way to solve actual problem.
|
|
|
|
if (mInputContext.mIMEState.mEnabled == IMEState::PASSWORD) {
|
2014-01-28 09:02:08 +00:00
|
|
|
purpose = GTK_INPUT_PURPOSE_PASSWORD;
|
|
|
|
} else if (inputType.EqualsLiteral("email")) {
|
|
|
|
purpose = GTK_INPUT_PURPOSE_EMAIL;
|
|
|
|
} else if (inputType.EqualsLiteral("url")) {
|
|
|
|
purpose = GTK_INPUT_PURPOSE_URL;
|
|
|
|
} else if (inputType.EqualsLiteral("tel")) {
|
|
|
|
purpose = GTK_INPUT_PURPOSE_PHONE;
|
|
|
|
} else if (inputType.EqualsLiteral("number")) {
|
|
|
|
purpose = GTK_INPUT_PURPOSE_NUMBER;
|
|
|
|
}
|
|
|
|
|
|
|
|
g_object_set(currentContext, "input-purpose", purpose, nullptr);
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2011-11-27 11:51:53 +00:00
|
|
|
}
|
2018-01-09 10:51:07 +00:00
|
|
|
#endif // #ifdef MOZ_WIDGET_GTK
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2014-01-28 09:02:08 +00:00
|
|
|
// Even when aState is not enabled state, we need to set IME focus.
|
|
|
|
// Because some IMs are updating the status bar of them at this time.
|
|
|
|
// Be aware, don't use aWindow here because this method shouldn't move
|
|
|
|
// focus actually.
|
2018-11-30 10:46:48 +00:00
|
|
|
Focus();
|
|
|
|
|
2014-01-28 09:02:08 +00:00
|
|
|
// XXX Should we call Blur() when it's not editable? E.g., it might be
|
|
|
|
// better to close VKB automatically.
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
InputContext IMContextWrapper::GetInputContext() {
|
2011-11-27 11:51:53 +00:00
|
|
|
mInputContext.mIMEState.mOpen = IMEState::OPEN_STATE_NOT_SUPPORTED;
|
2011-11-27 11:51:52 +00:00
|
|
|
return mInputContext;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
GtkIMContext* IMContextWrapper::GetCurrentContext() const {
|
2010-03-19 04:21:16 +00:00
|
|
|
if (IsEnabled()) {
|
|
|
|
return mContext;
|
|
|
|
}
|
2013-10-29 09:04:59 +00:00
|
|
|
if (mInputContext.mIMEState.mEnabled == IMEState::PASSWORD) {
|
|
|
|
return mSimpleContext;
|
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
return mDummyContext;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
bool IMContextWrapper::IsValidContext(GtkIMContext* aContext) const {
|
2014-10-23 17:17:15 +00:00
|
|
|
if (!aContext) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return aContext == mContext || aContext == mSimpleContext ||
|
|
|
|
aContext == mDummyContext;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
bool IMContextWrapper::IsEnabled() const {
|
2011-11-27 11:51:53 +00:00
|
|
|
return mInputContext.mIMEState.mEnabled == IMEState::ENABLED ||
|
2014-01-28 09:02:08 +00:00
|
|
|
mInputContext.mIMEState.mEnabled == IMEState::PLUGIN ||
|
|
|
|
(!sUseSimpleContext &&
|
|
|
|
mInputContext.mIMEState.mEnabled == IMEState::PASSWORD);
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::Focus() {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p Focus(), sLastFocusedContext=0x%p", this, sLastFocusedContext));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
if (mIsIMFocused) {
|
2015-07-26 23:23:04 +00:00
|
|
|
NS_ASSERTION(sLastFocusedContext == this,
|
2010-03-19 04:21:16 +00:00
|
|
|
"We're not active, but the IM was focused?");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-11-10 09:07:44 +00:00
|
|
|
GtkIMContext* currentContext = GetCurrentContext();
|
|
|
|
if (!currentContext) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p Focus(), FAILED, there are no context", this));
|
2010-03-19 04:21:16 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
if (sLastFocusedContext && sLastFocusedContext != this) {
|
|
|
|
sLastFocusedContext->Blur();
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
sLastFocusedContext = this;
|
2010-03-19 04:21:16 +00:00
|
|
|
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
// Forget all posted key events when focus is moved since they shouldn't
|
|
|
|
// be fired in different editor.
|
2018-12-28 07:02:05 +00:00
|
|
|
sWaitingSynthesizedKeyPressHardwareKeyCode = 0;
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
mPostingKeyEvents.Clear();
|
|
|
|
|
2014-11-10 09:07:44 +00:00
|
|
|
gtk_im_context_focus_in(currentContext);
|
2011-10-03 07:56:21 +00:00
|
|
|
mIsIMFocused = true;
|
2015-06-26 07:08:29 +00:00
|
|
|
mSetCursorPositionOnKeyEvent = true;
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
if (!IsEnabled()) {
|
|
|
|
// We should release IME focus for uim and scim.
|
|
|
|
// These IMs are using snooper that is released at losing focus.
|
|
|
|
Blur();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::Blur() {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p Blur(), mIsIMFocused=%s", this, ToChar(mIsIMFocused)));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
if (!mIsIMFocused) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-11-10 09:07:44 +00:00
|
|
|
GtkIMContext* currentContext = GetCurrentContext();
|
|
|
|
if (!currentContext) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p Blur(), FAILED, there are no context", this));
|
2010-03-19 04:21:16 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-11-10 09:07:44 +00:00
|
|
|
gtk_im_context_focus_out(currentContext);
|
2011-10-03 07:56:21 +00:00
|
|
|
mIsIMFocused = false;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
2014-09-26 00:05:13 +00:00
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnSelectionChange(
|
|
|
|
nsWindow* aCaller, const IMENotification& aIMENotification) {
|
2015-06-11 10:50:15 +00:00
|
|
|
mSelection.Assign(aIMENotification);
|
2016-09-15 13:36:23 +00:00
|
|
|
bool retrievedSurroundingSignalReceived = mRetrieveSurroundingSignalReceived;
|
|
|
|
mRetrieveSurroundingSignalReceived = false;
|
2014-09-26 00:05:13 +00:00
|
|
|
|
2015-08-21 16:43:41 +00:00
|
|
|
if (MOZ_UNLIKELY(IsDestroyed())) {
|
2015-07-17 04:27:32 +00:00
|
|
|
return;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-07-17 04:27:32 +00:00
|
|
|
|
2015-08-21 16:43:41 +00:00
|
|
|
const IMENotification::SelectionChangeDataBase& selectionChangeData =
|
2015-07-17 04:27:32 +00:00
|
|
|
aIMENotification.mSelectionChangeData;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnSelectionChange(aCaller=0x%p, aIMENotification={ "
|
2015-07-22 03:40:32 +00:00
|
|
|
"mSelectionChangeData={ mOffset=%u, Length()=%u, mReversed=%s, "
|
2015-10-26 22:21:37 +00:00
|
|
|
"mWritingMode=%s, mCausedByComposition=%s, "
|
|
|
|
"mCausedBySelectionEvent=%s, mOccurredDuringComposition=%s "
|
2016-09-15 13:36:23 +00:00
|
|
|
"} }), mCompositionState=%s, mIsDeletingSurrounding=%s, "
|
|
|
|
"mRetrieveSurroundingSignalReceived=%s",
|
2015-07-17 04:27:32 +00:00
|
|
|
this, aCaller, selectionChangeData.mOffset,
|
2015-07-26 23:23:04 +00:00
|
|
|
selectionChangeData.Length(), ToChar(selectionChangeData.mReversed),
|
2015-07-17 04:27:32 +00:00
|
|
|
GetWritingModeName(selectionChangeData.GetWritingMode()).get(),
|
2015-07-26 23:23:04 +00:00
|
|
|
ToChar(selectionChangeData.mCausedByComposition),
|
|
|
|
ToChar(selectionChangeData.mCausedBySelectionEvent),
|
2015-10-26 22:21:37 +00:00
|
|
|
ToChar(selectionChangeData.mOccurredDuringComposition),
|
2016-09-15 13:36:23 +00:00
|
|
|
GetCompositionStateName(), ToChar(mIsDeletingSurrounding),
|
|
|
|
ToChar(retrievedSurroundingSignalReceived)));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2014-09-26 00:05:13 +00:00
|
|
|
if (aCaller != mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnSelectionChange(), FAILED, "
|
|
|
|
"the caller isn't focused window, mLastFocusedWindow=0x%p",
|
2015-07-26 23:23:04 +00:00
|
|
|
this, mLastFocusedWindow));
|
2014-09-26 00:05:13 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-06-15 07:01:39 +00:00
|
|
|
if (!IsComposing()) {
|
|
|
|
// Now we have no composition (mostly situation on calling this method)
|
2016-05-31 02:39:15 +00:00
|
|
|
// If we have it, it will set by
|
|
|
|
// NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED.
|
2015-06-26 07:08:29 +00:00
|
|
|
mSetCursorPositionOnKeyEvent = true;
|
2015-06-15 07:01:39 +00:00
|
|
|
}
|
|
|
|
|
2015-05-03 17:02:50 +00:00
|
|
|
// The focused editor might have placeholder text with normal text node.
|
|
|
|
// In such case, the text node must be removed from a compositionstart
|
2015-09-11 12:21:27 +00:00
|
|
|
// event handler. So, we're dispatching eCompositionStart,
|
2015-05-03 17:02:50 +00:00
|
|
|
// we should ignore selection change notification.
|
|
|
|
if (mCompositionState == eCompositionState_CompositionStartDispatched) {
|
2015-06-11 10:50:15 +00:00
|
|
|
if (NS_WARN_IF(!mSelection.IsValid())) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnSelectionChange(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"new offset is too large, cannot keep composing",
|
|
|
|
this));
|
2015-06-11 10:50:15 +00:00
|
|
|
} else {
|
2015-05-03 17:02:50 +00:00
|
|
|
// Modify the selection start offset with new offset.
|
2015-06-11 10:50:15 +00:00
|
|
|
mCompositionStart = mSelection.mOffset;
|
2017-06-27 09:46:08 +00:00
|
|
|
// XXX We should modify mSelectedStringRemovedByComposition?
|
|
|
|
// But how?
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnSelectionChange(), ignored, mCompositionStart "
|
2015-07-26 23:23:04 +00:00
|
|
|
"is updated to %u, the selection change doesn't cause "
|
|
|
|
"resetting IM context",
|
|
|
|
this, mCompositionStart));
|
2015-05-03 17:02:50 +00:00
|
|
|
// And don't reset the IM context.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
// Otherwise, reset the IM context due to impossible to keep composing.
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-05-03 17:02:50 +00:00
|
|
|
|
2015-03-17 07:07:02 +00:00
|
|
|
// If the selection change is caused by deleting surrounding text,
|
|
|
|
// we shouldn't need to notify IME of selection change.
|
|
|
|
if (mIsDeletingSurrounding) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-10-26 22:21:37 +00:00
|
|
|
bool occurredBeforeComposition =
|
2016-09-16 09:00:25 +00:00
|
|
|
IsComposing() && !selectionChangeData.mOccurredDuringComposition &&
|
|
|
|
!selectionChangeData.mCausedByComposition;
|
2015-10-26 22:21:37 +00:00
|
|
|
if (occurredBeforeComposition) {
|
|
|
|
mPendingResettingIMContext = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// When the selection change is caused by dispatching composition event,
|
|
|
|
// selection set event and/or occurred before starting current composition,
|
|
|
|
// we shouldn't notify IME of that and commit existing composition.
|
2015-07-17 04:27:32 +00:00
|
|
|
if (!selectionChangeData.mCausedByComposition &&
|
2015-10-26 22:21:37 +00:00
|
|
|
!selectionChangeData.mCausedBySelectionEvent &&
|
|
|
|
!occurredBeforeComposition) {
|
2016-09-15 13:36:23 +00:00
|
|
|
// Hack for ibus-pinyin. ibus-pinyin will synthesize a set of
|
|
|
|
// composition which commits with empty string after calling
|
|
|
|
// gtk_im_context_reset(). Therefore, selecting text causes
|
|
|
|
// unexpectedly removing it. For preventing it but not breaking the
|
|
|
|
// other IMEs which use surrounding text, we should call it only when
|
|
|
|
// surrounding text has been retrieved after last selection range was
|
|
|
|
// set. If it's not retrieved, that means that current IME doesn't
|
|
|
|
// have any content cache, so, it must not need the notification of
|
|
|
|
// selection change.
|
|
|
|
if (IsComposing() || retrievedSurroundingSignalReceived) {
|
|
|
|
ResetIME();
|
2015-07-17 04:27:32 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2014-09-26 00:05:13 +00:00
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2018-07-13 09:12:53 +00:00
|
|
|
/* static */
|
|
|
|
void IMContextWrapper::OnThemeChanged() {
|
|
|
|
if (!SelectionStyleProvider::GetInstance()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
SelectionStyleProvider::GetInstance()->OnThemeChanged();
|
|
|
|
}
|
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
/* static */
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnStartCompositionCallback(GtkIMContext* aContext,
|
|
|
|
IMContextWrapper* aModule) {
|
2010-03-19 04:21:16 +00:00
|
|
|
aModule->OnStartCompositionNative(aContext);
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnStartCompositionNative(GtkIMContext* aContext) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnStartCompositionNative(aContext=0x%p), "
|
2017-09-04 11:18:43 +00:00
|
|
|
"current context=0x%p, mComposingContext=0x%p",
|
|
|
|
this, aContext, GetCurrentContext(), mComposingContext));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
// See bug 472635, we should do nothing if IM context doesn't match.
|
2014-11-10 09:07:44 +00:00
|
|
|
if (GetCurrentContext() != aContext) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnStartCompositionNative(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"given context doesn't match",
|
|
|
|
this));
|
2010-03-19 04:21:16 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-09-04 11:18:43 +00:00
|
|
|
if (mComposingContext && aContext != mComposingContext) {
|
|
|
|
// XXX For now, we should ignore this odd case, just logging.
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p OnStartCompositionNative(), Warning, "
|
|
|
|
"there is already a composing context but starting new "
|
|
|
|
"composition with different context",
|
|
|
|
this));
|
|
|
|
}
|
|
|
|
|
|
|
|
// IME may start composition without "preedit_start" signal. Therefore,
|
|
|
|
// mComposingContext will be initialized in DispatchCompositionStart().
|
2014-11-10 09:07:44 +00:00
|
|
|
|
2014-11-10 09:07:43 +00:00
|
|
|
if (!DispatchCompositionStart(aContext)) {
|
2010-03-19 04:21:16 +00:00
|
|
|
return;
|
|
|
|
}
|
2015-06-11 10:50:15 +00:00
|
|
|
mCompositionTargetRange.mOffset = mCompositionStart;
|
|
|
|
mCompositionTargetRange.mLength = 0;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* static */
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnEndCompositionCallback(GtkIMContext* aContext,
|
|
|
|
IMContextWrapper* aModule) {
|
2010-03-19 04:21:16 +00:00
|
|
|
aModule->OnEndCompositionNative(aContext);
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnEndCompositionNative(GtkIMContext* aContext) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2017-09-04 11:18:43 +00:00
|
|
|
("0x%p OnEndCompositionNative(aContext=0x%p), mComposingContext=0x%p",
|
|
|
|
this, aContext, mComposingContext));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
// See bug 472635, we should do nothing if IM context doesn't match.
|
2014-10-23 17:17:15 +00:00
|
|
|
// Note that if this is called after focus move, the context may different
|
2014-11-10 09:07:44 +00:00
|
|
|
// from any our owning context.
|
2014-10-23 17:17:15 +00:00
|
|
|
if (!IsValidContext(aContext)) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnEndCompositionNative(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"given context doesn't match with any context",
|
|
|
|
this));
|
2010-03-19 04:21:16 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-09-04 11:18:43 +00:00
|
|
|
// If we've not started composition with aContext, we should ignore it.
|
|
|
|
if (aContext != mComposingContext) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p OnEndCompositionNative(), Warning, "
|
|
|
|
"given context doesn't match with mComposingContext",
|
|
|
|
this));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-11-10 09:07:44 +00:00
|
|
|
g_object_unref(mComposingContext);
|
|
|
|
mComposingContext = nullptr;
|
|
|
|
|
2015-10-26 22:21:37 +00:00
|
|
|
// If we already handled the commit event, we should do nothing here.
|
|
|
|
if (IsComposing()) {
|
|
|
|
if (!DispatchCompositionCommitEvent(aContext)) {
|
|
|
|
// If the widget is destroyed, we should do nothing anymore.
|
|
|
|
return;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2015-10-26 22:21:37 +00:00
|
|
|
if (mPendingResettingIMContext) {
|
|
|
|
ResetIME();
|
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* static */
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnChangeCompositionCallback(GtkIMContext* aContext,
|
|
|
|
IMContextWrapper* aModule) {
|
2010-03-19 04:21:16 +00:00
|
|
|
aModule->OnChangeCompositionNative(aContext);
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnChangeCompositionNative(GtkIMContext* aContext) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2017-09-04 11:18:43 +00:00
|
|
|
("0x%p OnChangeCompositionNative(aContext=0x%p), "
|
|
|
|
"mComposingContext=0x%p",
|
|
|
|
this, aContext, mComposingContext));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
// See bug 472635, we should do nothing if IM context doesn't match.
|
2014-10-23 17:17:15 +00:00
|
|
|
// Note that if this is called after focus move, the context may different
|
2014-11-10 09:07:44 +00:00
|
|
|
// from any our owning context.
|
2014-10-23 17:17:15 +00:00
|
|
|
if (!IsValidContext(aContext)) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnChangeCompositionNative(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"given context doesn't match with any context",
|
|
|
|
this));
|
2010-03-19 04:21:16 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-09-04 11:18:43 +00:00
|
|
|
if (mComposingContext && aContext != mComposingContext) {
|
|
|
|
// XXX For now, we should ignore this odd case, just logging.
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p OnChangeCompositionNative(), Warning, "
|
|
|
|
"given context doesn't match with composing context",
|
|
|
|
this));
|
|
|
|
}
|
|
|
|
|
2011-09-22 09:17:40 +00:00
|
|
|
nsAutoString compositionString;
|
2014-10-23 17:17:15 +00:00
|
|
|
GetCompositionString(aContext, compositionString);
|
2012-03-09 04:27:51 +00:00
|
|
|
if (!IsComposing() && compositionString.IsEmpty()) {
|
2017-09-04 11:18:43 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p OnChangeCompositionNative(), Warning, does nothing "
|
|
|
|
"because has not started composition and composing string is "
|
|
|
|
"empty",
|
|
|
|
this));
|
2011-09-22 09:17:40 +00:00
|
|
|
mDispatchedCompositionString.Truncate();
|
2010-03-19 04:21:16 +00:00
|
|
|
return; // Don't start the composition with empty string.
|
|
|
|
}
|
|
|
|
|
2011-09-22 09:17:40 +00:00
|
|
|
// Be aware, widget can be gone
|
2014-11-10 09:07:43 +00:00
|
|
|
DispatchCompositionChangeEvent(aContext, compositionString);
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2010-03-24 15:04:39 +00:00
|
|
|
/* static */
|
2015-07-26 23:23:04 +00:00
|
|
|
gboolean IMContextWrapper::OnRetrieveSurroundingCallback(
|
|
|
|
GtkIMContext* aContext, IMContextWrapper* aModule) {
|
2010-03-24 15:04:39 +00:00
|
|
|
return aModule->OnRetrieveSurroundingNative(aContext);
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
gboolean IMContextWrapper::OnRetrieveSurroundingNative(GtkIMContext* aContext) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnRetrieveSurroundingNative(aContext=0x%p), "
|
|
|
|
"current context=0x%p",
|
2014-11-10 09:07:44 +00:00
|
|
|
this, aContext, GetCurrentContext()));
|
2010-03-24 15:04:39 +00:00
|
|
|
|
2014-11-10 09:07:43 +00:00
|
|
|
// See bug 472635, we should do nothing if IM context doesn't match.
|
2014-11-10 09:07:44 +00:00
|
|
|
if (GetCurrentContext() != aContext) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnRetrieveSurroundingNative(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"given context doesn't match",
|
|
|
|
this));
|
2010-03-24 15:04:39 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsAutoString uniStr;
|
2012-08-22 15:56:38 +00:00
|
|
|
uint32_t cursorPos;
|
2010-03-24 15:04:39 +00:00
|
|
|
if (NS_FAILED(GetCurrentParagraph(uniStr, cursorPos))) {
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2012-06-03 03:27:48 +00:00
|
|
|
NS_ConvertUTF16toUTF8 utf8Str(nsDependentSubstring(uniStr, 0, cursorPos));
|
2012-08-22 15:56:38 +00:00
|
|
|
uint32_t cursorPosInUTF8 = utf8Str.Length();
|
2012-06-03 03:27:48 +00:00
|
|
|
AppendUTF16toUTF8(nsDependentSubstring(uniStr, cursorPos), utf8Str);
|
|
|
|
gtk_im_context_set_surrounding(aContext, utf8Str.get(), utf8Str.Length(),
|
|
|
|
cursorPosInUTF8);
|
2016-09-15 13:36:23 +00:00
|
|
|
mRetrieveSurroundingSignalReceived = true;
|
2010-03-24 15:04:39 +00:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* static */
|
2015-07-26 23:23:04 +00:00
|
|
|
gboolean IMContextWrapper::OnDeleteSurroundingCallback(
|
|
|
|
GtkIMContext* aContext, gint aOffset, gint aNChars,
|
|
|
|
IMContextWrapper* aModule) {
|
2010-03-24 15:04:39 +00:00
|
|
|
return aModule->OnDeleteSurroundingNative(aContext, aOffset, aNChars);
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
gboolean IMContextWrapper::OnDeleteSurroundingNative(GtkIMContext* aContext,
|
|
|
|
gint aOffset,
|
|
|
|
gint aNChars) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnDeleteSurroundingNative(aContext=0x%p, aOffset=%d, "
|
|
|
|
"aNChar=%d), current context=0x%p",
|
2016-06-27 01:40:02 +00:00
|
|
|
this, aContext, aOffset, aNChars, GetCurrentContext()));
|
2010-03-24 15:04:39 +00:00
|
|
|
|
2014-11-10 09:07:43 +00:00
|
|
|
// See bug 472635, we should do nothing if IM context doesn't match.
|
2014-11-10 09:07:44 +00:00
|
|
|
if (GetCurrentContext() != aContext) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnDeleteSurroundingNative(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"given context doesn't match",
|
|
|
|
this));
|
2010-03-24 15:04:39 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2015-03-17 07:07:02 +00:00
|
|
|
AutoRestore<bool> saveDeletingSurrounding(mIsDeletingSurrounding);
|
|
|
|
mIsDeletingSurrounding = true;
|
2014-11-10 09:07:43 +00:00
|
|
|
if (NS_SUCCEEDED(DeleteText(aContext, aOffset, (uint32_t)aNChars))) {
|
2010-03-24 15:04:39 +00:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
// failed
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnDeleteSurroundingNative(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"cannot delete text",
|
|
|
|
this));
|
2010-03-24 15:04:39 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
2017-12-19 10:38:59 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
/* static */
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnCommitCompositionCallback(GtkIMContext* aContext,
|
|
|
|
const gchar* aString,
|
|
|
|
IMContextWrapper* aModule) {
|
2010-03-19 04:21:16 +00:00
|
|
|
aModule->OnCommitCompositionNative(aContext, aString);
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::OnCommitCompositionNative(GtkIMContext* aContext,
|
|
|
|
const gchar* aUTF8Char) {
|
2011-03-25 01:08:00 +00:00
|
|
|
const gchar emptyStr = 0;
|
|
|
|
const gchar* commitString = aUTF8Char ? aUTF8Char : &emptyStr;
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
NS_ConvertUTF8toUTF16 utf16CommitString(commitString);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnCommitCompositionNative(aContext=0x%p), "
|
|
|
|
"current context=0x%p, active context=0x%p, commitString=\"%s\", "
|
|
|
|
"mProcessingKeyEvent=0x%p, IsComposingOn(aContext)=%s",
|
2015-03-19 16:52:24 +00:00
|
|
|
this, aContext, GetCurrentContext(), GetActiveContext(),
|
2015-07-26 23:23:04 +00:00
|
|
|
commitString, mProcessingKeyEvent, ToChar(IsComposingOn(aContext))));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
// See bug 472635, we should do nothing if IM context doesn't match.
|
2015-03-19 16:52:24 +00:00
|
|
|
if (!IsValidContext(aContext)) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnCommitCompositionNative(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"given context doesn't match",
|
|
|
|
this));
|
2010-03-19 04:21:16 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2011-03-25 01:08:00 +00:00
|
|
|
// If we are not in composition and committing with empty string,
|
|
|
|
// we need to do nothing because if we continued to handle this
|
|
|
|
// signal, we would dispatch compositionstart, text, compositionend
|
|
|
|
// events with empty string. Of course, they are unnecessary events
|
|
|
|
// for Web applications and our editor.
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
if (!IsComposingOn(aContext) && utf16CommitString.IsEmpty()) {
|
2017-09-04 11:18:43 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p OnCommitCompositionNative(), Warning, does nothing "
|
|
|
|
"because has not started composition and commit string is empty",
|
|
|
|
this));
|
2011-03-25 01:08:00 +00:00
|
|
|
return;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
// If IME doesn't change their keyevent that generated this commit,
|
2018-02-22 11:56:08 +00:00
|
|
|
// we should treat that IME didn't handle the key event because
|
|
|
|
// web applications want to receive "keydown" and "keypress" event
|
|
|
|
// in such case.
|
2015-03-19 16:52:24 +00:00
|
|
|
// NOTE: While a key event is being handled, this might be caused on
|
|
|
|
// current context. Otherwise, this may be caused on active context.
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
if (!IsComposingOn(aContext) && mProcessingKeyEvent &&
|
2018-02-22 11:56:08 +00:00
|
|
|
mProcessingKeyEvent->type == GDK_KEY_PRESS &&
|
2015-03-19 16:52:24 +00:00
|
|
|
aContext == GetCurrentContext()) {
|
2010-03-19 04:21:16 +00:00
|
|
|
char keyval_utf8[8]; /* should have at least 6 bytes of space */
|
|
|
|
gint keyval_utf8_len;
|
|
|
|
guint32 keyval_unicode;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
keyval_unicode = gdk_keyval_to_unicode(mProcessingKeyEvent->keyval);
|
|
|
|
keyval_utf8_len = g_unichar_to_utf8(keyval_unicode, keyval_utf8);
|
|
|
|
keyval_utf8[keyval_utf8_len] = '\0';
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
// If committing string is exactly same as a character which is
|
|
|
|
// produced by the key, eKeyDown and eKeyPress event should be
|
|
|
|
// dispatched by the caller of OnKeyEvent() normally. Note that
|
|
|
|
// mMaybeInDeadKeySequence will be set to false by OnKeyEvent()
|
|
|
|
// since we set mFallbackToKeyEvent to true here.
|
2011-03-25 01:08:00 +00:00
|
|
|
if (!strcmp(commitString, keyval_utf8)) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnCommitCompositionNative(), "
|
2015-07-26 23:23:04 +00:00
|
|
|
"we'll send normal key event",
|
2018-11-30 10:46:48 +00:00
|
|
|
this));
|
2018-02-22 11:56:08 +00:00
|
|
|
mFallbackToKeyEvent = true;
|
2018-11-30 10:46:48 +00:00
|
|
|
return;
|
2011-03-25 01:08:00 +00:00
|
|
|
}
|
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
// If we're in a dead key sequence, commit string is a character in
|
2015-03-19 16:52:24 +00:00
|
|
|
// the BMP and mProcessingKeyEvent produces some characters but it's
|
2010-03-19 04:21:16 +00:00
|
|
|
// not same as committing string, we should dispatch an eKeyPress
|
|
|
|
// event from here.
|
|
|
|
WidgetKeyboardEvent keyDownEvent(true, eKeyDown, mLastFocusedWindow);
|
|
|
|
KeymapWrapper::InitKeyEvent(keyDownEvent, mProcessingKeyEvent, false);
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
if (mMaybeInDeadKeySequence && utf16CommitString.Length() == 1 &&
|
|
|
|
keyDownEvent.mKeyNameIndex == KEY_NAME_INDEX_USE_STRING) {
|
|
|
|
mKeyboardEventWasDispatched = true;
|
|
|
|
// Anyway, we're not in dead key sequence anymore.
|
|
|
|
mMaybeInDeadKeySequence = false;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
RefPtr<TextEventDispatcher> dispatcher = GetTextEventDispatcher();
|
|
|
|
nsresult rv = dispatcher->BeginNativeInputTransaction();
|
2011-03-25 01:08:00 +00:00
|
|
|
if (NS_WARN_IF(NS_FAILED(rv))) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnCommitCompositionNative(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"due to BeginNativeInputTransaction() failure",
|
2010-03-19 04:21:16 +00:00
|
|
|
this));
|
|
|
|
return;
|
|
|
|
}
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
|
|
|
|
// First, dispatch eKeyDown event.
|
|
|
|
keyDownEvent.mKeyValue = utf16CommitString;
|
|
|
|
nsEventStatus status = nsEventStatus_eIgnore;
|
|
|
|
bool dispatched = dispatcher->DispatchKeyboardEvent(
|
|
|
|
eKeyDown, keyDownEvent, status, mProcessingKeyEvent);
|
|
|
|
if (!dispatched || status == nsEventStatus_eConsumeNoDefault) {
|
Bug 1505147 - nsWindow::OnKeyPressEvent() shouldn't dispatch eKeyDown event when IMContextWrapper::OnKeyEvent() has already dispatched it for the event r=m_kato
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
2018-11-26 03:26:39 +00:00
|
|
|
mKeyboardEventWasConsumed = true;
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p OnCommitCompositionNative(), "
|
|
|
|
"doesn't dispatch eKeyPress event because the preceding "
|
|
|
|
"eKeyDown event was not dispatched or was consumed",
|
|
|
|
this));
|
|
|
|
return;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
if (mLastFocusedWindow != keyDownEvent.mWidget ||
|
|
|
|
mLastFocusedWindow->Destroyed()) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p OnCommitCompositionNative(), Warning, "
|
|
|
|
"stop dispatching eKeyPress event because the preceding "
|
|
|
|
"eKeyDown event caused changing focused widget or "
|
|
|
|
"destroyed",
|
|
|
|
this));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnCommitCompositionNative(), "
|
2018-02-22 11:56:08 +00:00
|
|
|
"dispatched eKeyDown event for the committed character",
|
2018-11-30 10:46:48 +00:00
|
|
|
this));
|
|
|
|
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
// Next, dispatch eKeyPress event.
|
|
|
|
dispatcher->MaybeDispatchKeypressEvents(keyDownEvent, status,
|
|
|
|
mProcessingKeyEvent);
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p OnCommitCompositionNative(), "
|
2018-02-22 11:56:08 +00:00
|
|
|
"dispatched eKeyPress event for the committed character",
|
2018-11-30 10:46:48 +00:00
|
|
|
this));
|
|
|
|
return;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2011-03-25 01:08:00 +00:00
|
|
|
NS_ConvertUTF8toUTF16 str(commitString);
|
2014-11-10 09:07:43 +00:00
|
|
|
// Be aware, widget can be gone
|
2014-11-25 05:02:34 +00:00
|
|
|
DispatchCompositionCommitEvent(aContext, &str);
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::GetCompositionString(GtkIMContext* aContext,
|
|
|
|
nsAString& aCompositionString) {
|
2010-03-19 04:21:16 +00:00
|
|
|
gchar* preedit_string;
|
|
|
|
gint cursor_pos;
|
|
|
|
PangoAttrList* feedback_list;
|
2014-10-23 17:17:15 +00:00
|
|
|
gtk_im_context_get_preedit_string(aContext, &preedit_string, &feedback_list,
|
2010-03-19 04:21:16 +00:00
|
|
|
&cursor_pos);
|
|
|
|
if (preedit_string && *preedit_string) {
|
2018-07-06 07:44:43 +00:00
|
|
|
CopyUTF8toUTF16(MakeStringSpan(preedit_string), aCompositionString);
|
2010-03-19 04:21:16 +00:00
|
|
|
} else {
|
|
|
|
aCompositionString.Truncate();
|
|
|
|
}
|
|
|
|
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p GetCompositionString(aContext=0x%p), "
|
2015-07-26 23:23:04 +00:00
|
|
|
"aCompositionString=\"%s\"",
|
|
|
|
this, aContext, preedit_string));
|
2010-04-14 11:27:20 +00:00
|
|
|
|
|
|
|
pango_attr_list_unref(feedback_list);
|
|
|
|
g_free(preedit_string);
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
bool IMContextWrapper::MaybeDispatchKeyEventAsProcessedByIME(
|
|
|
|
EventMessage aFollowingEvent) {
|
|
|
|
if (!mLastFocusedWindow) {
|
2018-02-22 11:56:08 +00:00
|
|
|
return false;
|
|
|
|
}
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
if (!mIsKeySnooped &&
|
|
|
|
((!mProcessingKeyEvent && mPostingKeyEvents.IsEmpty()) ||
|
|
|
|
(mProcessingKeyEvent && mKeyboardEventWasDispatched))) {
|
|
|
|
return true;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
// A "keydown" or "keyup" event handler may change focus with the
|
|
|
|
// following event. In such case, we need to cancel this composition.
|
|
|
|
// So, we need to store IM context now because mComposingContext may be
|
2018-02-22 11:56:08 +00:00
|
|
|
// overwritten with different context if calling this method recursively.
|
|
|
|
// Note that we don't need to grab the context here because |context|
|
|
|
|
// will be used only for checking if it's same as mComposingContext.
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
GtkIMContext* oldCurrentContext = GetCurrentContext();
|
|
|
|
GtkIMContext* oldComposingContext = mComposingContext;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
RefPtr<nsWindow> lastFocusedWindow(mLastFocusedWindow);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
if (mProcessingKeyEvent || !mPostingKeyEvents.IsEmpty()) {
|
|
|
|
if (mProcessingKeyEvent) {
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
mKeyboardEventWasDispatched = true;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
// If we're not handling a key event synchronously, the signal may be
|
|
|
|
// sent by IME without sending key event to us. In such case, we
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
// should dispatch keyboard event for the last key event which was
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
// posted to other IME process.
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
GdkEventKey* sourceEvent = mProcessingKeyEvent
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
? mProcessingKeyEvent
|
|
|
|
: mPostingKeyEvents.GetFirstEvent();
|
2018-11-30 10:46:48 +00:00
|
|
|
|
|
|
|
MOZ_LOG(
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
gGtkIMLog, LogLevel::Info,
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
("0x%p MaybeDispatchKeyEventAsProcessedByIME("
|
|
|
|
"aFollowingEvent=%s), dispatch %s %s "
|
|
|
|
"event: { type=%s, keyval=%s, unicode=0x%X, state=%s, "
|
|
|
|
"time=%u, hardware_keycode=%u, group=%u }",
|
|
|
|
this, ToChar(aFollowingEvent),
|
|
|
|
ToChar(sourceEvent->type == GDK_KEY_PRESS ? eKeyDown : eKeyUp),
|
|
|
|
mProcessingKeyEvent ? "processing" : "posted",
|
|
|
|
GetEventType(sourceEvent), gdk_keyval_name(sourceEvent->keyval),
|
|
|
|
gdk_keyval_to_unicode(sourceEvent->keyval),
|
|
|
|
GetEventStateName(sourceEvent->state, mIMContextID).get(),
|
|
|
|
sourceEvent->time, sourceEvent->hardware_keycode, sourceEvent->group));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
// Let's dispatch eKeyDown event or eKeyUp event now. Note that only
|
|
|
|
// when we're not in a dead key composition, we should mark the
|
|
|
|
// eKeyDown and eKeyUp event as "processed by IME" since we should
|
|
|
|
// expose raw keyCode and key value to web apps the key event is a
|
|
|
|
// part of a dead key sequence.
|
|
|
|
// FYI: We should ignore if default of preceding keydown or keyup
|
|
|
|
// event is prevented since even on the other browsers, web
|
|
|
|
// applications cannot cancel the following composition event.
|
|
|
|
// Spec bug: https://github.com/w3c/uievents/issues/180
|
2019-01-07 23:15:33 +00:00
|
|
|
KeymapWrapper::DispatchKeyDownOrKeyUpEvent(lastFocusedWindow, sourceEvent,
|
|
|
|
!mMaybeInDeadKeySequence,
|
|
|
|
&mKeyboardEventWasConsumed);
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p MaybeDispatchKeyEventAsProcessedByIME(), keydown or keyup "
|
|
|
|
"event is dispatched",
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
this));
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
|
|
|
|
if (!mProcessingKeyEvent) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p MaybeDispatchKeyEventAsProcessedByIME(), removing first "
|
|
|
|
"event from the queue",
|
|
|
|
this));
|
|
|
|
mPostingKeyEvents.RemoveEvent(sourceEvent);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
MOZ_ASSERT(mIsKeySnooped);
|
|
|
|
// Currently, we support key snooper mode of uim only.
|
|
|
|
MOZ_ASSERT(mIMContextID == IMContextID::eUim);
|
|
|
|
// uim sends "preedit_start" signal and "preedit_changed" separately
|
|
|
|
// at starting composition, "commit" and "preedit_end" separately at
|
|
|
|
// committing composition.
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
// Currently, we should dispatch only fake eKeyDown event because
|
|
|
|
// we cannot decide which is the last signal of each key operation
|
|
|
|
// and Chromium also dispatches only "keydown" event in this case.
|
|
|
|
bool dispatchFakeKeyDown = false;
|
|
|
|
switch (aFollowingEvent) {
|
|
|
|
case eCompositionStart:
|
|
|
|
case eCompositionCommit:
|
|
|
|
case eCompositionCommitAsIs:
|
|
|
|
dispatchFakeKeyDown = true;
|
|
|
|
break;
|
|
|
|
// XXX Unfortunately, I don't have a good idea to prevent to
|
|
|
|
// dispatch redundant eKeyDown event for eCompositionStart
|
|
|
|
// immediately after "delete_surrounding" signal. However,
|
|
|
|
// not dispatching eKeyDown event is worse than dispatching
|
|
|
|
// redundant eKeyDown events.
|
|
|
|
case eContentCommandDelete:
|
|
|
|
dispatchFakeKeyDown = true;
|
|
|
|
break;
|
|
|
|
// We need to prevent to dispatch redundant eKeyDown event for
|
|
|
|
// eCompositionChange immediately after eCompositionStart. So,
|
|
|
|
// We should not dispatch eKeyDown event if dispatched composition
|
|
|
|
// string is still empty string.
|
|
|
|
case eCompositionChange:
|
|
|
|
dispatchFakeKeyDown = !mDispatchedCompositionString.IsEmpty();
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
MOZ_ASSERT_UNREACHABLE("Do you forget to handle the case?");
|
|
|
|
break;
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
if (dispatchFakeKeyDown) {
|
|
|
|
WidgetKeyboardEvent fakeKeyDownEvent(true, eKeyDown, lastFocusedWindow);
|
|
|
|
fakeKeyDownEvent.mKeyCode = NS_VK_PROCESSKEY;
|
|
|
|
fakeKeyDownEvent.mKeyNameIndex = KEY_NAME_INDEX_Process;
|
|
|
|
// It's impossible to get physical key information in this case but
|
|
|
|
// this should be okay since web apps shouldn't do anything with
|
|
|
|
// physical key information during composition.
|
|
|
|
fakeKeyDownEvent.mCodeNameIndex = CODE_NAME_INDEX_UNKNOWN;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p MaybeDispatchKeyEventAsProcessedByIME("
|
|
|
|
"aFollowingEvent=%s), dispatch fake eKeyDown event",
|
|
|
|
this, ToChar(aFollowingEvent)));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2019-01-07 23:15:33 +00:00
|
|
|
KeymapWrapper::DispatchKeyDownOrKeyUpEvent(
|
|
|
|
lastFocusedWindow, fakeKeyDownEvent, &mKeyboardEventWasConsumed);
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
|
|
|
("0x%p MaybeDispatchKeyEventAsProcessedByIME(), "
|
|
|
|
"fake keydown event is dispatched",
|
|
|
|
this));
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
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
2018-03-09 03:39:40 +00:00
|
|
|
|
2018-02-22 11:56:08 +00:00
|
|
|
if (lastFocusedWindow->IsDestroyed() ||
|
|
|
|
lastFocusedWindow != mLastFocusedWindow) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p MaybeDispatchKeyEventAsProcessedByIME(), Warning, the "
|
|
|
|
"focused widget was destroyed/changed by a key event",
|
|
|
|
this));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the dispatched keydown event caused moving focus and that also
|
|
|
|
// caused changing active context, we need to cancel composition here.
|
|
|
|
if (GetCurrentContext() != oldCurrentContext) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p MaybeDispatchKeyEventAsProcessedByIME(), Warning, the key "
|
|
|
|
"event causes changing active IM context",
|
|
|
|
this));
|
|
|
|
if (mComposingContext == oldComposingContext) {
|
|
|
|
// Only when the context is still composing, we should call
|
|
|
|
// ResetIME() here. Otherwise, it should've already been
|
|
|
|
// cleaned up.
|
|
|
|
ResetIME();
|
|
|
|
}
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
return false;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2018-02-22 11:56:08 +00:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
bool IMContextWrapper::DispatchCompositionStart(GtkIMContext* aContext) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionStart(aContext=0x%p)", this, aContext));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2012-03-09 04:27:51 +00:00
|
|
|
if (IsComposing()) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionStart(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"we're already in composition",
|
|
|
|
this));
|
2011-10-03 07:56:21 +00:00
|
|
|
return true;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionStart(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"there are no focused window in this module",
|
|
|
|
this));
|
2011-10-03 07:56:21 +00:00
|
|
|
return false;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-06-11 10:50:15 +00:00
|
|
|
if (NS_WARN_IF(!EnsureToCacheSelection())) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionStart(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"cannot query the selection offset",
|
|
|
|
this));
|
2011-10-03 07:56:21 +00:00
|
|
|
return false;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2017-09-04 11:18:43 +00:00
|
|
|
mComposingContext = static_cast<GtkIMContext*>(g_object_ref(aContext));
|
|
|
|
MOZ_ASSERT(mComposingContext);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2016-07-18 18:14:10 +00:00
|
|
|
// Keep the last focused window alive
|
2018-02-22 11:56:08 +00:00
|
|
|
RefPtr<nsWindow> lastFocusedWindow(mLastFocusedWindow);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2012-03-09 04:27:51 +00:00
|
|
|
// XXX The composition start point might be changed by composition events
|
|
|
|
// even though we strongly hope it doesn't happen.
|
|
|
|
// Every composition event should have the start offset for the result
|
|
|
|
// because it may high cost if we query the offset every time.
|
2015-06-11 10:50:15 +00:00
|
|
|
mCompositionStart = mSelection.mOffset;
|
2011-09-22 09:17:40 +00:00
|
|
|
mDispatchedCompositionString.Truncate();
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2018-02-22 11:56:08 +00:00
|
|
|
// If this composition is started by a key press, we need to dispatch
|
|
|
|
// eKeyDown or eKeyUp event before dispatching eCompositionStart event.
|
|
|
|
// Note that dispatching a keyboard event which is marked as "processed
|
|
|
|
// by IME" is okay since Chromium also dispatches keyboard event as so.
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
if (!MaybeDispatchKeyEventAsProcessedByIME(eCompositionStart)) {
|
2018-02-22 11:56:08 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p DispatchCompositionStart(), Warning, "
|
|
|
|
"MaybeDispatchKeyEventAsProcessedByIME() returned false",
|
2015-07-26 23:23:04 +00:00
|
|
|
this));
|
2018-02-22 11:56:08 +00:00
|
|
|
return false;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2016-03-16 04:47:49 +00:00
|
|
|
RefPtr<TextEventDispatcher> dispatcher = GetTextEventDispatcher();
|
|
|
|
nsresult rv = dispatcher->BeginNativeInputTransaction();
|
|
|
|
if (NS_WARN_IF(NS_FAILED(rv))) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionStart(), FAILED, "
|
2016-03-16 04:47:49 +00:00
|
|
|
"due to BeginNativeInputTransaction() failure",
|
|
|
|
this));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-06-20 05:55:46 +00:00
|
|
|
static bool sHasSetTelemetry = false;
|
|
|
|
if (!sHasSetTelemetry) {
|
|
|
|
sHasSetTelemetry = true;
|
|
|
|
NS_ConvertUTF8toUTF16 im(GetIMName());
|
|
|
|
// 72 is kMaximumKeyStringLength in TelemetryScalar.cpp
|
|
|
|
if (im.Length() > 72) {
|
|
|
|
if (NS_IS_LOW_SURROGATE(im[72 - 1]) && NS_IS_HIGH_SURROGATE(im[72 - 2])) {
|
|
|
|
im.Truncate(72 - 2);
|
|
|
|
} else {
|
|
|
|
im.Truncate(72 - 1);
|
|
|
|
}
|
|
|
|
// U+2026 is "..."
|
|
|
|
im.Append(char16_t(0x2026));
|
|
|
|
}
|
|
|
|
Telemetry::ScalarSet(Telemetry::ScalarID::WIDGET_IME_NAME_ON_LINUX, im,
|
2018-11-30 10:46:48 +00:00
|
|
|
true);
|
|
|
|
}
|
2018-06-20 05:55:46 +00:00
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionStart(), dispatching "
|
2016-03-16 04:47:49 +00:00
|
|
|
"compositionstart... (mCompositionStart=%u)",
|
2015-07-26 23:23:04 +00:00
|
|
|
this, mCompositionStart));
|
2012-03-09 04:27:51 +00:00
|
|
|
mCompositionState = eCompositionState_CompositionStartDispatched;
|
2015-06-11 10:50:15 +00:00
|
|
|
nsEventStatus status;
|
2016-03-16 04:47:49 +00:00
|
|
|
dispatcher->StartComposition(status);
|
|
|
|
if (lastFocusedWindow->IsDestroyed() ||
|
|
|
|
lastFocusedWindow != mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionStart(), FAILED, the focused "
|
2015-07-26 23:23:04 +00:00
|
|
|
"widget was destroyed/changed by compositionstart event",
|
|
|
|
this));
|
2011-10-03 07:56:21 +00:00
|
|
|
return false;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2011-10-03 07:56:21 +00:00
|
|
|
return true;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
bool IMContextWrapper::DispatchCompositionChangeEvent(
|
|
|
|
GtkIMContext* aContext, const nsAString& aCompositionString) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionChangeEvent(aContext=0x%p)", this, aContext));
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
if (!mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionChangeEvent(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"there are no focused window in this module",
|
|
|
|
this));
|
2011-10-03 07:56:21 +00:00
|
|
|
return false;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2012-03-09 04:27:51 +00:00
|
|
|
if (!IsComposing()) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionChangeEvent(), the composition "
|
2015-07-26 23:23:04 +00:00
|
|
|
"wasn't started, force starting...",
|
|
|
|
this));
|
2014-11-10 09:07:43 +00:00
|
|
|
if (!DispatchCompositionStart(aContext)) {
|
2011-10-03 07:56:21 +00:00
|
|
|
return false;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2018-02-22 11:56:08 +00:00
|
|
|
// If this composition string change caused by a key press, we need to
|
|
|
|
// dispatch eKeyDown or eKeyUp before dispatching eCompositionChange event.
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
else if (!MaybeDispatchKeyEventAsProcessedByIME(eCompositionChange)) {
|
2018-02-22 11:56:08 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p DispatchCompositionChangeEvent(), Warning, "
|
|
|
|
"MaybeDispatchKeyEventAsProcessedByIME() returned false",
|
|
|
|
this));
|
|
|
|
return false;
|
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2016-03-16 04:47:49 +00:00
|
|
|
RefPtr<TextEventDispatcher> dispatcher = GetTextEventDispatcher();
|
|
|
|
nsresult rv = dispatcher->BeginNativeInputTransaction();
|
|
|
|
if (NS_WARN_IF(NS_FAILED(rv))) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionChangeEvent(), FAILED, "
|
2016-03-16 04:47:49 +00:00
|
|
|
"due to BeginNativeInputTransaction() failure",
|
|
|
|
this));
|
|
|
|
return false;
|
|
|
|
}
|
2011-09-22 09:17:40 +00:00
|
|
|
|
2014-10-07 10:01:47 +00:00
|
|
|
// Store the selected string which will be removed by following
|
|
|
|
// compositionchange event.
|
2012-03-09 04:27:51 +00:00
|
|
|
if (mCompositionState == eCompositionState_CompositionStartDispatched) {
|
2017-06-27 09:46:08 +00:00
|
|
|
if (NS_WARN_IF(
|
|
|
|
!EnsureToCacheSelection(&mSelectedStringRemovedByComposition))) {
|
2015-06-11 10:50:15 +00:00
|
|
|
// XXX How should we behave in this case??
|
|
|
|
} else {
|
|
|
|
// XXX We should assume, for now, any web applications don't change
|
|
|
|
// selection at handling this compositionchange event.
|
|
|
|
mCompositionStart = mSelection.mOffset;
|
2012-03-09 04:27:51 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2012-03-09 04:27:51 +00:00
|
|
|
|
2016-03-16 04:47:49 +00:00
|
|
|
RefPtr<TextRangeArray> rangeArray =
|
|
|
|
CreateTextRangeArray(aContext, aCompositionString);
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2016-03-16 04:47:49 +00:00
|
|
|
rv = dispatcher->SetPendingComposition(aCompositionString, rangeArray);
|
|
|
|
if (NS_WARN_IF(NS_FAILED(rv))) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionChangeEvent(), FAILED, "
|
2016-03-16 04:47:49 +00:00
|
|
|
"due to SetPendingComposition() failure",
|
|
|
|
this));
|
|
|
|
return false;
|
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2014-11-10 09:07:42 +00:00
|
|
|
mCompositionState = eCompositionState_CompositionChangeEventDispatched;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-06-11 10:50:15 +00:00
|
|
|
// We cannot call SetCursorPosition for e10s-aware.
|
|
|
|
// DispatchEvent is async on e10s, so composition rect isn't updated now
|
|
|
|
// on tab parent.
|
2016-03-16 04:47:49 +00:00
|
|
|
mDispatchedCompositionString = aCompositionString;
|
2015-06-11 10:50:15 +00:00
|
|
|
mLayoutChanged = false;
|
2016-07-14 06:43:47 +00:00
|
|
|
mCompositionTargetRange.mOffset =
|
|
|
|
mCompositionStart + rangeArray->TargetClauseOffset();
|
2016-03-16 04:47:49 +00:00
|
|
|
mCompositionTargetRange.mLength = rangeArray->TargetClauseLength();
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2016-03-16 04:47:49 +00:00
|
|
|
RefPtr<nsWindow> lastFocusedWindow(mLastFocusedWindow);
|
|
|
|
nsEventStatus status;
|
|
|
|
rv = dispatcher->FlushPendingComposition(status);
|
|
|
|
if (NS_WARN_IF(NS_FAILED(rv))) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionChangeEvent(), FAILED, "
|
2016-03-16 04:47:49 +00:00
|
|
|
"due to FlushPendingComposition() failure",
|
|
|
|
this));
|
|
|
|
return false;
|
|
|
|
}
|
2015-06-11 10:50:15 +00:00
|
|
|
|
2011-09-22 09:17:40 +00:00
|
|
|
if (lastFocusedWindow->IsDestroyed() ||
|
|
|
|
lastFocusedWindow != mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionChangeEvent(), FAILED, the "
|
2015-07-26 23:23:04 +00:00
|
|
|
"focused widget was destroyed/changed by "
|
|
|
|
"compositionchange event",
|
|
|
|
this));
|
2011-10-03 07:56:21 +00:00
|
|
|
return false;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
2011-10-03 07:56:21 +00:00
|
|
|
return true;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
bool IMContextWrapper::DispatchCompositionCommitEvent(
|
|
|
|
GtkIMContext* aContext, const nsAString* aCommitString) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionCommitEvent(aContext=0x%p, "
|
|
|
|
"aCommitString=0x%p, (\"%s\"))",
|
2014-11-25 05:02:34 +00:00
|
|
|
this, aContext, aCommitString,
|
|
|
|
aCommitString ? NS_ConvertUTF16toUTF8(*aCommitString).get() : ""));
|
2014-11-10 09:07:42 +00:00
|
|
|
|
|
|
|
if (!mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionCommitEvent(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"there are no focused window in this module",
|
|
|
|
this));
|
2014-11-10 09:07:42 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-02-22 11:56:08 +00:00
|
|
|
// TODO: We need special care to handle request to commit composition
|
|
|
|
// by content while we're committing composition because we have
|
|
|
|
// commit string information now but IME may not have composition
|
|
|
|
// anymore. Therefore, we may not be able to handle commit as
|
|
|
|
// expected. However, this is rare case because this situation
|
|
|
|
// never occurs with remote content. So, it's okay to fix this
|
|
|
|
// issue later. (Perhaps, TextEventDisptcher should do it for
|
|
|
|
// all platforms. E.g., creating WillCommitComposition()?)
|
2014-11-10 09:07:42 +00:00
|
|
|
if (!IsComposing()) {
|
2014-11-25 05:02:34 +00:00
|
|
|
if (!aCommitString || aCommitString->IsEmpty()) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionCommitEvent(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"there is no composition and empty commit string",
|
|
|
|
this));
|
2014-11-12 08:52:19 +00:00
|
|
|
return true;
|
|
|
|
}
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionCommitEvent(), "
|
2015-07-26 23:23:04 +00:00
|
|
|
"the composition wasn't started, force starting...",
|
|
|
|
this));
|
2014-11-12 08:52:19 +00:00
|
|
|
if (!DispatchCompositionStart(aContext)) {
|
|
|
|
return false;
|
2014-11-10 09:07:42 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2018-02-22 11:56:08 +00:00
|
|
|
// If this commit caused by a key press, we need to dispatch eKeyDown or
|
|
|
|
// eKeyUp before dispatching composition events.
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
else if (!MaybeDispatchKeyEventAsProcessedByIME(
|
|
|
|
aCommitString ? eCompositionCommit : eCompositionCommitAsIs)) {
|
2018-02-22 11:56:08 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p DispatchCompositionCommitEvent(), Warning, "
|
|
|
|
"MaybeDispatchKeyEventAsProcessedByIME() returned false",
|
|
|
|
this));
|
|
|
|
mCompositionState = eCompositionState_NotComposing;
|
|
|
|
return false;
|
|
|
|
}
|
2014-11-10 09:07:42 +00:00
|
|
|
|
2016-03-16 04:47:49 +00:00
|
|
|
RefPtr<TextEventDispatcher> dispatcher = GetTextEventDispatcher();
|
|
|
|
nsresult rv = dispatcher->BeginNativeInputTransaction();
|
|
|
|
if (NS_WARN_IF(NS_FAILED(rv))) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionCommitEvent(), FAILED, "
|
2016-03-16 04:47:49 +00:00
|
|
|
"due to BeginNativeInputTransaction() failure",
|
|
|
|
this));
|
|
|
|
return false;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2014-11-10 09:07:42 +00:00
|
|
|
|
2016-07-18 18:14:10 +00:00
|
|
|
RefPtr<nsWindow> lastFocusedWindow(mLastFocusedWindow);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
Bug 1376407 - part2: Emulate selection when committing composition as collapsed to the end of composition r=m_kato
When you start new composition during converting with Mozc in e10s mode, the following things occur:
1. Mozc commits previous composition.
2. Gecko dispatches eCompositionCommit event.
3. Mozc sets new composition string (skipping composition start signal).
4. Gecko dispatches eCompositionStart and eCompositionChange event.
5. Selection is changed asynchronously.
6. Gecko sets position of IME windows.
At #4, Gecko stores start of composition as selection start, then, trying to adjust it at #5. However, new selection is caret position in new composition string. Therefore, it's not used for the adjustment. This causes that stored composition start offset is always the start of the previous composition (if the previous patch didn't change EnsureToCacheSelection() behavior). So, IMContextWrapper needs to compute proper composition start offset in this case.
The simplest fix is, modifying selection at #2 as which will be occurred in focused editor. So, this patch makes the selection cache collapsed to the end of committing string.
Note that actual selection may be different if JS changes selection and/or the text in the focused editor. However, it doesn't matter. IMContextWrapper should behave as expected while current composition is active.
MozReview-Commit-ID: 221mDUd8yRP
--HG--
extra : rebase_source : 571b2de85ed6ea1fdadea73b7f95507937cc60e9
2017-06-27 10:11:25 +00:00
|
|
|
// Emulate selection until receiving actual selection range.
|
|
|
|
mSelection.CollapseTo(
|
2017-09-04 11:18:43 +00:00
|
|
|
mCompositionStart + (aCommitString
|
Bug 1376407 - part2: Emulate selection when committing composition as collapsed to the end of composition r=m_kato
When you start new composition during converting with Mozc in e10s mode, the following things occur:
1. Mozc commits previous composition.
2. Gecko dispatches eCompositionCommit event.
3. Mozc sets new composition string (skipping composition start signal).
4. Gecko dispatches eCompositionStart and eCompositionChange event.
5. Selection is changed asynchronously.
6. Gecko sets position of IME windows.
At #4, Gecko stores start of composition as selection start, then, trying to adjust it at #5. However, new selection is caret position in new composition string. Therefore, it's not used for the adjustment. This causes that stored composition start offset is always the start of the previous composition (if the previous patch didn't change EnsureToCacheSelection() behavior). So, IMContextWrapper needs to compute proper composition start offset in this case.
The simplest fix is, modifying selection at #2 as which will be occurred in focused editor. So, this patch makes the selection cache collapsed to the end of committing string.
Note that actual selection may be different if JS changes selection and/or the text in the focused editor. However, it doesn't matter. IMContextWrapper should behave as expected while current composition is active.
MozReview-Commit-ID: 221mDUd8yRP
--HG--
extra : rebase_source : 571b2de85ed6ea1fdadea73b7f95507937cc60e9
2017-06-27 10:11:25 +00:00
|
|
|
? aCommitString->Length()
|
|
|
|
: mDispatchedCompositionString.Length()),
|
|
|
|
mSelection.mWritingMode);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2014-11-10 09:07:42 +00:00
|
|
|
mCompositionState = eCompositionState_NotComposing;
|
Bug 1443091 - IMContextWrapper should dispatch eKeyDown and eKeyUp event as "Dead" keys rather than "Process" if user pressed a dead key r=m_kato
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
2018-03-05 13:03:58 +00:00
|
|
|
// Reset dead key sequence too because GTK doesn't support dead key chain
|
|
|
|
// (i.e., a key press doesn't cause both producing some characters and
|
|
|
|
// restarting new dead key sequence at one time). So, committing
|
|
|
|
// composition means end of a dead key sequence.
|
|
|
|
mMaybeInDeadKeySequence = false;
|
2014-11-10 09:07:42 +00:00
|
|
|
mCompositionStart = UINT32_MAX;
|
2015-06-11 10:50:15 +00:00
|
|
|
mCompositionTargetRange.Clear();
|
2011-09-22 09:17:40 +00:00
|
|
|
mDispatchedCompositionString.Truncate();
|
Bug 1376407 - part2: Emulate selection when committing composition as collapsed to the end of composition r=m_kato
When you start new composition during converting with Mozc in e10s mode, the following things occur:
1. Mozc commits previous composition.
2. Gecko dispatches eCompositionCommit event.
3. Mozc sets new composition string (skipping composition start signal).
4. Gecko dispatches eCompositionStart and eCompositionChange event.
5. Selection is changed asynchronously.
6. Gecko sets position of IME windows.
At #4, Gecko stores start of composition as selection start, then, trying to adjust it at #5. However, new selection is caret position in new composition string. Therefore, it's not used for the adjustment. This causes that stored composition start offset is always the start of the previous composition (if the previous patch didn't change EnsureToCacheSelection() behavior). So, IMContextWrapper needs to compute proper composition start offset in this case.
The simplest fix is, modifying selection at #2 as which will be occurred in focused editor. So, this patch makes the selection cache collapsed to the end of committing string.
Note that actual selection may be different if JS changes selection and/or the text in the focused editor. However, it doesn't matter. IMContextWrapper should behave as expected while current composition is active.
MozReview-Commit-ID: 221mDUd8yRP
--HG--
extra : rebase_source : 571b2de85ed6ea1fdadea73b7f95507937cc60e9
2017-06-27 10:11:25 +00:00
|
|
|
mSelectedStringRemovedByComposition.Truncate();
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2016-03-16 04:47:49 +00:00
|
|
|
nsEventStatus status;
|
|
|
|
rv = dispatcher->CommitComposition(status, aCommitString);
|
|
|
|
if (NS_WARN_IF(NS_FAILED(rv))) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionChangeEvent(), FAILED, "
|
2016-03-16 04:47:49 +00:00
|
|
|
"due to CommitComposition() failure",
|
|
|
|
this));
|
|
|
|
return false;
|
2014-11-10 09:07:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (lastFocusedWindow->IsDestroyed() ||
|
|
|
|
lastFocusedWindow != mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DispatchCompositionCommitEvent(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"the focused widget was destroyed/changed by "
|
|
|
|
"compositioncommit event",
|
|
|
|
this));
|
2014-11-10 09:07:42 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
already_AddRefed<TextRangeArray> IMContextWrapper::CreateTextRangeArray(
|
2015-08-19 07:37:39 +00:00
|
|
|
GtkIMContext* aContext, const nsAString& aCompositionString) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p CreateTextRangeArray(aContext=0x%p, "
|
2015-08-19 07:37:39 +00:00
|
|
|
"aCompositionString=\"%s\" (Length()=%u))",
|
|
|
|
this, aContext, NS_ConvertUTF16toUTF8(aCompositionString).get(),
|
|
|
|
aCompositionString.Length()));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-10-18 05:24:48 +00:00
|
|
|
RefPtr<TextRangeArray> textRangeArray = new TextRangeArray();
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
gchar* preedit_string;
|
2015-08-19 07:37:39 +00:00
|
|
|
gint cursor_pos_in_chars;
|
2010-03-19 04:21:16 +00:00
|
|
|
PangoAttrList* feedback_list;
|
2014-11-10 09:07:43 +00:00
|
|
|
gtk_im_context_get_preedit_string(aContext, &preedit_string, &feedback_list,
|
2015-08-19 07:37:39 +00:00
|
|
|
&cursor_pos_in_chars);
|
2010-03-19 04:21:16 +00:00
|
|
|
if (!preedit_string || !*preedit_string) {
|
2016-03-16 04:47:49 +00:00
|
|
|
if (!aCompositionString.IsEmpty()) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p CreateTextRangeArray(), FAILED, due to "
|
2016-03-16 04:47:49 +00:00
|
|
|
"preedit_string is null",
|
|
|
|
this));
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
pango_attr_list_unref(feedback_list);
|
|
|
|
g_free(preedit_string);
|
2014-03-04 13:48:27 +00:00
|
|
|
return textRangeArray.forget();
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
// Convert caret offset from offset in characters to offset in UTF-16
|
|
|
|
// string. If we couldn't proper offset in UTF-16 string, we should
|
|
|
|
// assume that the caret is at the end of the composition string.
|
2015-08-19 07:37:39 +00:00
|
|
|
uint32_t caretOffsetInUTF16 = aCompositionString.Length();
|
2015-08-19 07:37:39 +00:00
|
|
|
if (NS_WARN_IF(cursor_pos_in_chars < 0)) {
|
|
|
|
// Note that this case is undocumented. We should assume that the
|
|
|
|
// caret is at the end of the composition string.
|
|
|
|
} else if (cursor_pos_in_chars == 0) {
|
|
|
|
caretOffsetInUTF16 = 0;
|
2018-11-30 10:46:48 +00:00
|
|
|
} else {
|
2015-08-19 07:37:39 +00:00
|
|
|
gchar* charAfterCaret =
|
|
|
|
g_utf8_offset_to_pointer(preedit_string, cursor_pos_in_chars);
|
|
|
|
if (NS_WARN_IF(!charAfterCaret)) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p CreateTextRangeArray(), failed to get UTF-8 "
|
2015-08-19 07:37:39 +00:00
|
|
|
"string before the caret (cursor_pos_in_chars=%d)",
|
|
|
|
this, cursor_pos_in_chars));
|
|
|
|
} else {
|
|
|
|
glong caretOffset = 0;
|
|
|
|
gunichar2* utf16StrBeforeCaret =
|
|
|
|
g_utf8_to_utf16(preedit_string, charAfterCaret - preedit_string,
|
|
|
|
nullptr, &caretOffset, nullptr);
|
|
|
|
if (NS_WARN_IF(!utf16StrBeforeCaret) || NS_WARN_IF(caretOffset < 0)) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p CreateTextRangeArray(), WARNING, failed to "
|
2015-08-19 07:37:39 +00:00
|
|
|
"convert to UTF-16 string before the caret "
|
2016-12-16 03:16:31 +00:00
|
|
|
"(cursor_pos_in_chars=%d, caretOffset=%ld)",
|
2015-08-19 07:37:39 +00:00
|
|
|
this, cursor_pos_in_chars, caretOffset));
|
|
|
|
} else {
|
|
|
|
caretOffsetInUTF16 = static_cast<uint32_t>(caretOffset);
|
2015-08-19 07:37:39 +00:00
|
|
|
uint32_t compositionStringLength = aCompositionString.Length();
|
2015-08-19 07:37:39 +00:00
|
|
|
if (NS_WARN_IF(caretOffsetInUTF16 > compositionStringLength)) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p CreateTextRangeArray(), WARNING, "
|
2015-08-19 07:37:39 +00:00
|
|
|
"caretOffsetInUTF16=%u is larger than "
|
|
|
|
"compositionStringLength=%u",
|
|
|
|
this, caretOffsetInUTF16, compositionStringLength));
|
|
|
|
caretOffsetInUTF16 = compositionStringLength;
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-08-19 07:37:39 +00:00
|
|
|
if (utf16StrBeforeCaret) {
|
|
|
|
g_free(utf16StrBeforeCaret);
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-08-19 07:37:39 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-08-19 07:37:39 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
PangoAttrIterator* iter;
|
|
|
|
iter = pango_attr_list_get_iterator(feedback_list);
|
|
|
|
if (!iter) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p CreateTextRangeArray(), FAILED, iterator couldn't "
|
2015-07-26 23:23:04 +00:00
|
|
|
"be allocated",
|
|
|
|
this));
|
2010-03-19 04:21:16 +00:00
|
|
|
pango_attr_list_unref(feedback_list);
|
2015-08-19 07:37:39 +00:00
|
|
|
g_free(preedit_string);
|
2014-03-04 13:48:27 +00:00
|
|
|
return textRangeArray.forget();
|
Bug 1282043 IMContextWrapper shouldn't append 0 length clause to TextRangeArray and if IME doesn't specify clause at beginning of the composition, it should insert dummy clause r=m_kato
Here is the patched build's log:
[Main Thread]: I/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(aContext=7fab5a7bbbf0, aCompositionString="÷" (Length()=1))
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to no attr, aTextRange= { mStartOffset=0, mEndOffset=1 }
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to current clause length is 0
[Main Thread]: E/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to g_utf8_to_utf16() failure (retrieving current clause)
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(), inserting a dummy clause at the beginning of the composition string mStartOffset=0, mEndOffset=1, mRangeType=TextRangeType::eRawClause
iBus Chewing IME has two clauses when user presses Shift+p, one doesn't have pango_attr, the other is empty. These clauses are not useful in Gecko. Additionally, TextRangeArray assumes that there is a clause at beginning of the composition when there is one or more clauses. Therefore, this patch tries to insert dummy clause at the beggining of composition in such case.
MozReview-Commit-ID: 3hVGVmvFrhA
--HG--
extra : rebase_source : edbd3a6a1139cffb0d5bfbe0c92bf6870c9a2608
2016-06-28 10:37:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t minOffsetOfClauses = aCompositionString.Length();
|
2018-11-30 10:46:48 +00:00
|
|
|
do {
|
2013-10-01 07:22:59 +00:00
|
|
|
TextRange range;
|
2015-08-19 07:37:39 +00:00
|
|
|
if (!SetTextRange(iter, preedit_string, caretOffsetInUTF16, range)) {
|
2015-08-19 07:37:39 +00:00
|
|
|
continue;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-08-19 07:37:39 +00:00
|
|
|
MOZ_ASSERT(range.Length());
|
|
|
|
minOffsetOfClauses = std::min(minOffsetOfClauses, range.mStartOffset);
|
2014-03-04 13:48:27 +00:00
|
|
|
textRangeArray->AppendElement(range);
|
2010-03-19 04:21:16 +00:00
|
|
|
} while (pango_attr_iterator_next(iter));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
// If the IME doesn't define clause from the start of the composition,
|
Bug 1282043 IMContextWrapper shouldn't append 0 length clause to TextRangeArray and if IME doesn't specify clause at beginning of the composition, it should insert dummy clause r=m_kato
Here is the patched build's log:
[Main Thread]: I/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(aContext=7fab5a7bbbf0, aCompositionString="÷" (Length()=1))
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to no attr, aTextRange= { mStartOffset=0, mEndOffset=1 }
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to current clause length is 0
[Main Thread]: E/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to g_utf8_to_utf16() failure (retrieving current clause)
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(), inserting a dummy clause at the beginning of the composition string mStartOffset=0, mEndOffset=1, mRangeType=TextRangeType::eRawClause
iBus Chewing IME has two clauses when user presses Shift+p, one doesn't have pango_attr, the other is empty. These clauses are not useful in Gecko. Additionally, TextRangeArray assumes that there is a clause at beginning of the composition when there is one or more clauses. Therefore, this patch tries to insert dummy clause at the beggining of composition in such case.
MozReview-Commit-ID: 3hVGVmvFrhA
--HG--
extra : rebase_source : edbd3a6a1139cffb0d5bfbe0c92bf6870c9a2608
2016-06-28 10:37:03 +00:00
|
|
|
// we should insert dummy clause information since TextRangeArray assumes
|
|
|
|
// that there must be a clause whose start is 0 when there is one or
|
|
|
|
// more clauses.
|
|
|
|
if (minOffsetOfClauses) {
|
|
|
|
TextRange dummyClause;
|
|
|
|
dummyClause.mStartOffset = 0;
|
|
|
|
dummyClause.mEndOffset = minOffsetOfClauses;
|
|
|
|
dummyClause.mRangeType = TextRangeType::eRawClause;
|
|
|
|
textRangeArray->InsertElementAt(0, dummyClause);
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p CreateTextRangeArray(), inserting a dummy clause "
|
|
|
|
"at the beginning of the composition string mStartOffset=%u, "
|
2015-08-19 07:37:39 +00:00
|
|
|
"mEndOffset=%u, mRangeType=%s",
|
2015-07-26 23:23:04 +00:00
|
|
|
this, dummyClause.mStartOffset, dummyClause.mEndOffset,
|
2016-06-04 00:49:21 +00:00
|
|
|
ToChar(dummyClause.mRangeType)));
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2014-03-04 13:48:27 +00:00
|
|
|
|
2013-10-01 07:22:59 +00:00
|
|
|
TextRange range;
|
2015-08-19 07:37:39 +00:00
|
|
|
range.mStartOffset = range.mEndOffset = caretOffsetInUTF16;
|
2016-06-03 09:40:06 +00:00
|
|
|
range.mRangeType = TextRangeType::eCaret;
|
2014-03-04 13:48:27 +00:00
|
|
|
textRangeArray->AppendElement(range);
|
2018-11-30 10:46:48 +00:00
|
|
|
MOZ_LOG(
|
2015-08-19 07:37:39 +00:00
|
|
|
gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p CreateTextRangeArray(), mStartOffset=%u, "
|
Bug 1282043 IMContextWrapper shouldn't append 0 length clause to TextRangeArray and if IME doesn't specify clause at beginning of the composition, it should insert dummy clause r=m_kato
Here is the patched build's log:
[Main Thread]: I/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(aContext=7fab5a7bbbf0, aCompositionString="÷" (Length()=1))
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to no attr, aTextRange= { mStartOffset=0, mEndOffset=1 }
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to current clause length is 0
[Main Thread]: E/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to g_utf8_to_utf16() failure (retrieving current clause)
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(), inserting a dummy clause at the beginning of the composition string mStartOffset=0, mEndOffset=1, mRangeType=TextRangeType::eRawClause
iBus Chewing IME has two clauses when user presses Shift+p, one doesn't have pango_attr, the other is empty. These clauses are not useful in Gecko. Additionally, TextRangeArray assumes that there is a clause at beginning of the composition when there is one or more clauses. Therefore, this patch tries to insert dummy clause at the beggining of composition in such case.
MozReview-Commit-ID: 3hVGVmvFrhA
--HG--
extra : rebase_source : edbd3a6a1139cffb0d5bfbe0c92bf6870c9a2608
2016-06-28 10:37:03 +00:00
|
|
|
"mEndOffset=%u, mRangeType=%s",
|
2015-08-19 07:37:39 +00:00
|
|
|
this, range.mStartOffset, range.mEndOffset, ToChar(range.mRangeType)));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
pango_attr_iterator_destroy(iter);
|
|
|
|
pango_attr_list_unref(feedback_list);
|
|
|
|
g_free(preedit_string);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2014-03-04 13:48:27 +00:00
|
|
|
return textRangeArray.forget();
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
/* static */
|
|
|
|
nscolor IMContextWrapper::ToNscolor(PangoAttrColor* aPangoAttrColor) {
|
|
|
|
PangoColor& pangoColor = aPangoAttrColor->color;
|
|
|
|
uint8_t r = pangoColor.red / 0x100;
|
|
|
|
uint8_t g = pangoColor.green / 0x100;
|
|
|
|
uint8_t b = pangoColor.blue / 0x100;
|
|
|
|
return NS_RGB(r, g, b);
|
|
|
|
}
|
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
bool IMContextWrapper::SetTextRange(PangoAttrIterator* aPangoAttrIter,
|
|
|
|
const gchar* aUTF8CompositionString,
|
2015-08-19 07:37:39 +00:00
|
|
|
uint32_t aUTF16CaretOffset,
|
2015-08-19 07:37:39 +00:00
|
|
|
TextRange& aTextRange) const {
|
2015-08-19 07:37:39 +00:00
|
|
|
// Set the range offsets in UTF-16 string.
|
|
|
|
gint utf8ClauseStart, utf8ClauseEnd;
|
|
|
|
pango_attr_iterator_range(aPangoAttrIter, &utf8ClauseStart, &utf8ClauseEnd);
|
|
|
|
if (utf8ClauseStart == utf8ClauseEnd) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetTextRange(), FAILED, due to collapsed range", this));
|
2015-08-19 07:37:39 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!utf8ClauseStart) {
|
|
|
|
aTextRange.mStartOffset = 0;
|
|
|
|
} else {
|
|
|
|
glong utf16PreviousClausesLength;
|
|
|
|
gunichar2* utf16PreviousClausesString =
|
|
|
|
g_utf8_to_utf16(aUTF8CompositionString, utf8ClauseStart, nullptr,
|
|
|
|
&utf16PreviousClausesLength, nullptr);
|
|
|
|
|
|
|
|
if (NS_WARN_IF(!utf16PreviousClausesString)) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
|
|
|
("0x%p SetTextRange(), FAILED, due to g_utf8_to_utf16() "
|
|
|
|
"failure (retrieving previous string of current clause)",
|
|
|
|
this));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
aTextRange.mStartOffset = utf16PreviousClausesLength;
|
|
|
|
g_free(utf16PreviousClausesString);
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-08-19 07:37:39 +00:00
|
|
|
|
|
|
|
glong utf16CurrentClauseLength;
|
|
|
|
gunichar2* utf16CurrentClauseString = g_utf8_to_utf16(
|
2015-08-19 07:37:39 +00:00
|
|
|
aUTF8CompositionString + utf8ClauseStart, utf8ClauseEnd - utf8ClauseStart,
|
2015-08-19 07:37:39 +00:00
|
|
|
nullptr, &utf16CurrentClauseLength, nullptr);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
if (NS_WARN_IF(!utf16CurrentClauseString)) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetTextRange(), FAILED, due to g_utf8_to_utf16() "
|
2015-08-19 07:37:39 +00:00
|
|
|
"failure (retrieving current clause)",
|
|
|
|
this));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Bug 1282043 IMContextWrapper shouldn't append 0 length clause to TextRangeArray and if IME doesn't specify clause at beginning of the composition, it should insert dummy clause r=m_kato
Here is the patched build's log:
[Main Thread]: I/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(aContext=7fab5a7bbbf0, aCompositionString="÷" (Length()=1))
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to no attr, aTextRange= { mStartOffset=0, mEndOffset=1 }
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to current clause length is 0
[Main Thread]: E/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to g_utf8_to_utf16() failure (retrieving current clause)
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(), inserting a dummy clause at the beginning of the composition string mStartOffset=0, mEndOffset=1, mRangeType=TextRangeType::eRawClause
iBus Chewing IME has two clauses when user presses Shift+p, one doesn't have pango_attr, the other is empty. These clauses are not useful in Gecko. Additionally, TextRangeArray assumes that there is a clause at beginning of the composition when there is one or more clauses. Therefore, this patch tries to insert dummy clause at the beggining of composition in such case.
MozReview-Commit-ID: 3hVGVmvFrhA
--HG--
extra : rebase_source : edbd3a6a1139cffb0d5bfbe0c92bf6870c9a2608
2016-06-28 10:37:03 +00:00
|
|
|
// iBus Chewing IME tells us that there is an empty clause at the end of
|
|
|
|
// the composition string but we should ignore it since our code doesn't
|
|
|
|
// assume that there is an empty clause.
|
|
|
|
if (!utf16CurrentClauseLength) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetTextRange(), FAILED, due to current clause length "
|
Bug 1282043 IMContextWrapper shouldn't append 0 length clause to TextRangeArray and if IME doesn't specify clause at beginning of the composition, it should insert dummy clause r=m_kato
Here is the patched build's log:
[Main Thread]: I/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(aContext=7fab5a7bbbf0, aCompositionString="÷" (Length()=1))
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to no attr, aTextRange= { mStartOffset=0, mEndOffset=1 }
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to current clause length is 0
[Main Thread]: E/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to g_utf8_to_utf16() failure (retrieving current clause)
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(), inserting a dummy clause at the beginning of the composition string mStartOffset=0, mEndOffset=1, mRangeType=TextRangeType::eRawClause
iBus Chewing IME has two clauses when user presses Shift+p, one doesn't have pango_attr, the other is empty. These clauses are not useful in Gecko. Additionally, TextRangeArray assumes that there is a clause at beginning of the composition when there is one or more clauses. Therefore, this patch tries to insert dummy clause at the beggining of composition in such case.
MozReview-Commit-ID: 3hVGVmvFrhA
--HG--
extra : rebase_source : edbd3a6a1139cffb0d5bfbe0c92bf6870c9a2608
2016-06-28 10:37:03 +00:00
|
|
|
"is 0",
|
|
|
|
this));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
aTextRange.mEndOffset = aTextRange.mStartOffset + utf16CurrentClauseLength;
|
|
|
|
g_free(utf16CurrentClauseString);
|
|
|
|
utf16CurrentClauseString = nullptr;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
// Set styles
|
|
|
|
TextRangeStyle& style = aTextRange.mRangeStyle;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
// Underline
|
|
|
|
PangoAttrInt* attrUnderline = reinterpret_cast<PangoAttrInt*>(
|
|
|
|
pango_attr_iterator_get(aPangoAttrIter, PANGO_ATTR_UNDERLINE));
|
|
|
|
if (attrUnderline) {
|
|
|
|
switch (attrUnderline->value) {
|
|
|
|
case PANGO_UNDERLINE_NONE:
|
|
|
|
style.mLineStyle = TextRangeStyle::LINESTYLE_NONE;
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
2015-08-19 07:37:39 +00:00
|
|
|
case PANGO_UNDERLINE_DOUBLE:
|
|
|
|
style.mLineStyle = TextRangeStyle::LINESTYLE_DOUBLE;
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
2015-08-19 07:37:39 +00:00
|
|
|
case PANGO_UNDERLINE_ERROR:
|
|
|
|
style.mLineStyle = TextRangeStyle::LINESTYLE_WAVY;
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
2015-08-19 07:37:39 +00:00
|
|
|
case PANGO_UNDERLINE_SINGLE:
|
|
|
|
case PANGO_UNDERLINE_LOW:
|
|
|
|
style.mLineStyle = TextRangeStyle::LINESTYLE_SOLID;
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
|
|
|
default:
|
Bug 1282043 IMContextWrapper shouldn't append 0 length clause to TextRangeArray and if IME doesn't specify clause at beginning of the composition, it should insert dummy clause r=m_kato
Here is the patched build's log:
[Main Thread]: I/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(aContext=7fab5a7bbbf0, aCompositionString="÷" (Length()=1))
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to no attr, aTextRange= { mStartOffset=0, mEndOffset=1 }
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to current clause length is 0
[Main Thread]: E/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 SetTextRange(), FAILED, due to g_utf8_to_utf16() failure (retrieving current clause)
[Main Thread]: W/nsGtkIMModuleWidgets GTKIM: 7fab5a60a2c0 CreateTextRangeArray(), inserting a dummy clause at the beginning of the composition string mStartOffset=0, mEndOffset=1, mRangeType=TextRangeType::eRawClause
iBus Chewing IME has two clauses when user presses Shift+p, one doesn't have pango_attr, the other is empty. These clauses are not useful in Gecko. Additionally, TextRangeArray assumes that there is a clause at beginning of the composition when there is one or more clauses. Therefore, this patch tries to insert dummy clause at the beggining of composition in such case.
MozReview-Commit-ID: 3hVGVmvFrhA
--HG--
extra : rebase_source : edbd3a6a1139cffb0d5bfbe0c92bf6870c9a2608
2016-06-28 10:37:03 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetTextRange(), retrieved unknown underline "
|
2015-08-19 07:37:39 +00:00
|
|
|
"style: %d",
|
|
|
|
this, attrUnderline->value));
|
|
|
|
style.mLineStyle = TextRangeStyle::LINESTYLE_SOLID;
|
2018-11-30 10:46:48 +00:00
|
|
|
break;
|
|
|
|
}
|
2015-08-19 07:37:39 +00:00
|
|
|
style.mDefinedStyles |= TextRangeStyle::DEFINED_LINESTYLE;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
// Underline color
|
|
|
|
PangoAttrColor* attrUnderlineColor = reinterpret_cast<PangoAttrColor*>(
|
|
|
|
pango_attr_iterator_get(aPangoAttrIter, PANGO_ATTR_UNDERLINE_COLOR));
|
|
|
|
if (attrUnderlineColor) {
|
|
|
|
style.mUnderlineColor = ToNscolor(attrUnderlineColor);
|
|
|
|
style.mDefinedStyles |= TextRangeStyle::DEFINED_UNDERLINE_COLOR;
|
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
} else {
|
2015-08-19 07:37:39 +00:00
|
|
|
style.mLineStyle = TextRangeStyle::LINESTYLE_NONE;
|
|
|
|
style.mDefinedStyles |= TextRangeStyle::DEFINED_LINESTYLE;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-08-19 07:37:39 +00:00
|
|
|
|
|
|
|
// Don't set colors if they are not specified. They should be computed by
|
|
|
|
// textframe if only one of the colors are specified.
|
|
|
|
|
|
|
|
// Foreground color (text color)
|
|
|
|
PangoAttrColor* attrForeground = reinterpret_cast<PangoAttrColor*>(
|
|
|
|
pango_attr_iterator_get(aPangoAttrIter, PANGO_ATTR_FOREGROUND));
|
|
|
|
if (attrForeground) {
|
|
|
|
style.mForegroundColor = ToNscolor(attrForeground);
|
|
|
|
style.mDefinedStyles |= TextRangeStyle::DEFINED_FOREGROUND_COLOR;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Background color
|
|
|
|
PangoAttrColor* attrBackground = reinterpret_cast<PangoAttrColor*>(
|
|
|
|
pango_attr_iterator_get(aPangoAttrIter, PANGO_ATTR_BACKGROUND));
|
|
|
|
if (attrBackground) {
|
|
|
|
style.mBackgroundColor = ToNscolor(attrBackground);
|
|
|
|
style.mDefinedStyles |= TextRangeStyle::DEFINED_BACKGROUND_COLOR;
|
|
|
|
}
|
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
/**
|
2015-08-19 07:37:39 +00:00
|
|
|
* We need to judge the meaning of the clause for a11y. Before we support
|
|
|
|
* IME specific composition string style, we used following rules:
|
|
|
|
*
|
|
|
|
* 1: If attrUnderline and attrForground are specified, we assumed the
|
2016-06-03 10:15:21 +00:00
|
|
|
* clause is TextRangeType::eSelectedClause.
|
2015-08-19 07:37:39 +00:00
|
|
|
* 2: If only attrUnderline is specified, we assumed the clause is
|
2016-06-03 10:05:32 +00:00
|
|
|
* TextRangeType::eConvertedClause.
|
2015-08-19 07:37:39 +00:00
|
|
|
* 3: If only attrForground is specified, we assumed the clause is
|
2016-06-03 09:57:21 +00:00
|
|
|
* TextRangeType::eSelectedRawClause.
|
2015-08-19 07:37:39 +00:00
|
|
|
* 4: If neither attrUnderline nor attrForeground is specified, we assumed
|
2016-06-03 09:48:37 +00:00
|
|
|
* the clause is TextRangeType::eRawClause.
|
2015-08-19 07:37:39 +00:00
|
|
|
*
|
|
|
|
* However, this rules are odd since there can be two or more selected
|
|
|
|
* clauses. Additionally, our old rules caused that IME developers/users
|
|
|
|
* cannot specify composition string style as they want.
|
|
|
|
*
|
|
|
|
* So, we shouldn't guess the meaning from its visual style.
|
2015-08-19 07:37:39 +00:00
|
|
|
*/
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
if (!attrUnderline && !attrForeground && !attrBackground) {
|
2015-08-19 07:37:39 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetTextRange(), FAILED, due to no attr, "
|
2015-08-19 07:37:39 +00:00
|
|
|
"aTextRange= { mStartOffset=%u, mEndOffset=%u }",
|
|
|
|
this, aTextRange.mStartOffset, aTextRange.mEndOffset));
|
2015-08-19 07:37:39 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-08-19 07:37:39 +00:00
|
|
|
// If the range covers whole of composition string and the caret is at
|
|
|
|
// the end of the composition string, the range is probably not converted.
|
|
|
|
if (!utf8ClauseStart &&
|
|
|
|
utf8ClauseEnd == static_cast<gint>(strlen(aUTF8CompositionString)) &&
|
2015-08-19 07:37:39 +00:00
|
|
|
aTextRange.mEndOffset == aUTF16CaretOffset) {
|
2016-06-03 09:48:37 +00:00
|
|
|
aTextRange.mRangeType = TextRangeType::eRawClause;
|
2015-08-19 07:37:39 +00:00
|
|
|
}
|
|
|
|
// Typically, the caret is set at the start of the selected clause.
|
|
|
|
// So, if the caret is in the clause, we can assume that the clause is
|
|
|
|
// selected.
|
2015-08-19 07:37:39 +00:00
|
|
|
else if (aTextRange.mStartOffset <= aUTF16CaretOffset &&
|
|
|
|
aTextRange.mEndOffset > aUTF16CaretOffset) {
|
2016-06-03 10:15:21 +00:00
|
|
|
aTextRange.mRangeType = TextRangeType::eSelectedClause;
|
2015-08-19 07:37:39 +00:00
|
|
|
}
|
2015-08-19 07:37:39 +00:00
|
|
|
// Otherwise, we should assume that the clause is converted but not
|
|
|
|
// selected.
|
|
|
|
else {
|
2016-06-03 10:05:32 +00:00
|
|
|
aTextRange.mRangeType = TextRangeType::eConvertedClause;
|
2015-08-19 07:37:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetTextRange(), succeeded, aTextRange= { "
|
2015-08-19 07:37:39 +00:00
|
|
|
"mStartOffset=%u, mEndOffset=%u, mRangeType=%s, mRangeStyle=%s }",
|
2015-08-19 07:37:39 +00:00
|
|
|
this, aTextRange.mStartOffset, aTextRange.mEndOffset,
|
2016-06-04 00:49:21 +00:00
|
|
|
ToChar(aTextRange.mRangeType),
|
2015-08-19 07:37:39 +00:00
|
|
|
GetTextRangeStyleText(aTextRange.mRangeStyle).get()));
|
2015-08-19 07:37:39 +00:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::SetCursorPosition(GtkIMContext* aContext) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetCursorPosition(aContext=0x%p), "
|
2015-06-11 10:50:15 +00:00
|
|
|
"mCompositionTargetRange={ mOffset=%u, mLength=%u }"
|
2017-06-27 09:46:08 +00:00
|
|
|
"mSelection={ mOffset=%u, Length()=%u, mWritingMode=%s }",
|
2015-06-11 10:50:15 +00:00
|
|
|
this, aContext, mCompositionTargetRange.mOffset,
|
2017-06-27 09:46:08 +00:00
|
|
|
mCompositionTargetRange.mLength, mSelection.mOffset, mSelection.Length(),
|
2015-06-11 10:50:15 +00:00
|
|
|
GetWritingModeName(mSelection.mWritingMode).get()));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2015-06-15 07:01:39 +00:00
|
|
|
bool useCaret = false;
|
2015-06-11 10:50:15 +00:00
|
|
|
if (!mCompositionTargetRange.IsValid()) {
|
2015-06-15 07:01:39 +00:00
|
|
|
if (!mSelection.IsValid()) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetCursorPosition(), FAILED, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"mCompositionTargetRange and mSelection are invalid",
|
|
|
|
this));
|
2015-06-15 07:01:39 +00:00
|
|
|
return;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
2015-06-15 07:01:39 +00:00
|
|
|
useCaret = true;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
if (!mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetCursorPosition(), FAILED, due to no focused "
|
2015-07-26 23:23:04 +00:00
|
|
|
"window",
|
|
|
|
this));
|
2010-03-19 04:21:16 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-11-10 09:07:43 +00:00
|
|
|
if (MOZ_UNLIKELY(!aContext)) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetCursorPosition(), FAILED, due to no context", this));
|
2010-03-19 04:21:16 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-06-15 07:01:39 +00:00
|
|
|
WidgetQueryContentEvent charRect(
|
2015-09-10 01:40:06 +00:00
|
|
|
true, useCaret ? eQueryCaretRect : eQueryTextRect, mLastFocusedWindow);
|
2015-06-15 07:01:39 +00:00
|
|
|
if (useCaret) {
|
|
|
|
charRect.InitForQueryCaretRect(mSelection.mOffset);
|
2018-11-30 10:46:48 +00:00
|
|
|
} else {
|
2015-06-15 07:01:39 +00:00
|
|
|
if (mSelection.mWritingMode.IsVertical()) {
|
|
|
|
// For preventing the candidate window to overlap the target
|
|
|
|
// clause, we should set fake (typically, very tall) caret rect.
|
|
|
|
uint32_t length =
|
|
|
|
mCompositionTargetRange.mLength ? mCompositionTargetRange.mLength : 1;
|
|
|
|
charRect.InitForQueryTextRect(mCompositionTargetRange.mOffset, length);
|
2015-06-11 10:50:15 +00:00
|
|
|
} else {
|
2015-06-15 07:01:39 +00:00
|
|
|
charRect.InitForQueryTextRect(mCompositionTargetRange.mOffset, 1);
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2010-03-19 04:21:16 +00:00
|
|
|
InitEvent(charRect);
|
|
|
|
nsEventStatus status;
|
|
|
|
mLastFocusedWindow->DispatchEvent(&charRect, status);
|
|
|
|
if (!charRect.mSucceeded) {
|
2015-08-19 07:37:39 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p SetCursorPosition(), FAILED, %s was failed", this,
|
2015-09-11 12:21:26 +00:00
|
|
|
useCaret ? "eQueryCaretRect" : "eQueryTextRect"));
|
2018-11-30 10:46:48 +00:00
|
|
|
return;
|
|
|
|
}
|
2015-06-11 10:50:15 +00:00
|
|
|
|
2010-03-19 04:21:16 +00:00
|
|
|
nsWindow* rootWindow =
|
|
|
|
static_cast<nsWindow*>(mLastFocusedWindow->GetTopLevelWidget());
|
|
|
|
|
|
|
|
// Get the position of the rootWindow in screen.
|
2015-07-27 05:37:02 +00:00
|
|
|
LayoutDeviceIntPoint root = rootWindow->WidgetToScreenOffset();
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
// Get the position of IM context owner window in screen.
|
2015-07-27 05:37:02 +00:00
|
|
|
LayoutDeviceIntPoint owner = mOwnerWindow->WidgetToScreenOffset();
|
2010-03-19 04:21:16 +00:00
|
|
|
|
|
|
|
// Compute the caret position in the IM owner window.
|
2015-07-27 05:37:02 +00:00
|
|
|
LayoutDeviceIntRect rect = charRect.mReply.mRect + root - owner;
|
|
|
|
rect.width = 0;
|
2015-11-17 05:18:31 +00:00
|
|
|
GdkRectangle area = rootWindow->DevicePixelsToGdkRectRoundOut(rect);
|
2010-03-19 04:21:16 +00:00
|
|
|
|
2014-11-10 09:07:43 +00:00
|
|
|
gtk_im_context_set_cursor_location(aContext, &area);
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
nsresult IMContextWrapper::GetCurrentParagraph(nsAString& aText,
|
|
|
|
uint32_t& aCursorPos) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p GetCurrentParagraph(), mCompositionState=%s", this,
|
2012-03-09 04:27:51 +00:00
|
|
|
GetCompositionStateName()));
|
2010-03-24 15:04:39 +00:00
|
|
|
|
|
|
|
if (!mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p GetCurrentParagraph(), FAILED, there are no "
|
2015-07-26 23:23:04 +00:00
|
|
|
"focused window in this module",
|
|
|
|
this));
|
2010-03-24 15:04:39 +00:00
|
|
|
return NS_ERROR_NULL_POINTER;
|
|
|
|
}
|
|
|
|
|
2017-06-27 09:46:08 +00:00
|
|
|
nsEventStatus status;
|
2010-03-24 15:04:39 +00:00
|
|
|
|
2012-03-09 04:27:51 +00:00
|
|
|
uint32_t selOffset = mCompositionStart;
|
|
|
|
uint32_t selLength = mSelectedStringRemovedByComposition.Length();
|
|
|
|
|
2015-06-11 10:50:15 +00:00
|
|
|
// If focused editor doesn't have composition string, we should use
|
|
|
|
// current selection.
|
2017-06-27 09:46:08 +00:00
|
|
|
if (!EditorHasCompositionString()) {
|
|
|
|
// Query cursor position & selection
|
|
|
|
if (NS_WARN_IF(!EnsureToCacheSelection())) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
|
|
|
("0x%p GetCurrentParagraph(), FAILED, due to no "
|
2015-07-26 23:23:04 +00:00
|
|
|
"valid selection information",
|
2017-06-27 09:46:08 +00:00
|
|
|
this));
|
2015-06-11 10:50:15 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
2012-03-09 04:27:51 +00:00
|
|
|
}
|
|
|
|
|
2015-06-11 10:50:15 +00:00
|
|
|
selOffset = mSelection.mOffset;
|
2017-06-27 09:46:08 +00:00
|
|
|
selLength = mSelection.Length();
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p GetCurrentParagraph(), selOffset=%u, selLength=%u", this,
|
2015-07-26 23:23:04 +00:00
|
|
|
selOffset, selLength));
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2012-08-22 15:56:38 +00:00
|
|
|
// XXX nsString::Find and nsString::RFind take int32_t for offset, so,
|
2011-02-28 06:00:41 +00:00
|
|
|
// we cannot support this request when the current offset is larger
|
2012-09-28 06:57:33 +00:00
|
|
|
// than INT32_MAX.
|
|
|
|
if (selOffset > INT32_MAX || selLength > INT32_MAX ||
|
|
|
|
selOffset + selLength > INT32_MAX) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p GetCurrentParagraph(), FAILED, The selection is "
|
2015-07-26 23:23:04 +00:00
|
|
|
"out of range",
|
|
|
|
this));
|
2011-02-28 06:00:41 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
2010-03-24 15:04:39 +00:00
|
|
|
// Get all text contents of the focused editor
|
2015-09-10 01:40:05 +00:00
|
|
|
WidgetQueryContentEvent queryTextContentEvent(true, eQueryTextContent,
|
2013-10-01 07:23:00 +00:00
|
|
|
mLastFocusedWindow);
|
2012-09-28 06:57:33 +00:00
|
|
|
queryTextContentEvent.InitForQueryTextContent(0, UINT32_MAX);
|
2010-03-24 15:04:39 +00:00
|
|
|
mLastFocusedWindow->DispatchEvent(&queryTextContentEvent, status);
|
|
|
|
NS_ENSURE_TRUE(queryTextContentEvent.mSucceeded, NS_ERROR_FAILURE);
|
|
|
|
|
|
|
|
nsAutoString textContent(queryTextContentEvent.mReply.mString);
|
2011-02-28 06:00:41 +00:00
|
|
|
if (selOffset + selLength > textContent.Length()) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p GetCurrentParagraph(), FAILED, The selection is "
|
2015-07-26 23:23:04 +00:00
|
|
|
"invalid, textContent.Length()=%u",
|
|
|
|
this, textContent.Length()));
|
2010-03-24 15:04:39 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
2012-03-09 04:27:51 +00:00
|
|
|
// Remove composing string and restore the selected string because
|
|
|
|
// GtkEntry doesn't remove selected string until committing, however,
|
|
|
|
// our editor does it. We should emulate the behavior for IME.
|
|
|
|
if (EditorHasCompositionString() &&
|
2017-06-27 09:46:08 +00:00
|
|
|
mDispatchedCompositionString != mSelectedStringRemovedByComposition) {
|
2012-03-09 04:27:51 +00:00
|
|
|
textContent.Replace(mCompositionStart,
|
2017-06-27 09:46:08 +00:00
|
|
|
mDispatchedCompositionString.Length(),
|
|
|
|
mSelectedStringRemovedByComposition);
|
2012-03-09 04:27:51 +00:00
|
|
|
}
|
|
|
|
|
2010-03-24 15:04:39 +00:00
|
|
|
// Get only the focused paragraph, by looking for newlines
|
2012-08-22 15:56:38 +00:00
|
|
|
int32_t parStart =
|
|
|
|
(selOffset == 0) ? 0
|
2011-10-03 07:56:21 +00:00
|
|
|
: textContent.RFind("\n", false, selOffset - 1, -1) + 1;
|
2012-08-22 15:56:38 +00:00
|
|
|
int32_t parEnd = textContent.Find("\n", false, selOffset + selLength, -1);
|
2010-03-24 15:04:39 +00:00
|
|
|
if (parEnd < 0) {
|
|
|
|
parEnd = textContent.Length();
|
|
|
|
}
|
|
|
|
aText = nsDependentSubstring(textContent, parStart, parEnd - parStart);
|
2012-08-22 15:56:38 +00:00
|
|
|
aCursorPos = selOffset - uint32_t(parStart);
|
2011-02-28 06:00:41 +00:00
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p GetCurrentParagraph(), succeeded, aText=%s, "
|
2015-07-26 23:23:04 +00:00
|
|
|
"aText.Length()=%u, aCursorPos=%u",
|
|
|
|
this, NS_ConvertUTF16toUTF8(aText).get(), aText.Length(), aCursorPos));
|
2010-03-24 15:04:39 +00:00
|
|
|
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
nsresult IMContextWrapper::DeleteText(GtkIMContext* aContext, int32_t aOffset,
|
|
|
|
uint32_t aNChars) {
|
2015-06-03 22:25:57 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Info,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(aContext=0x%p, aOffset=%d, aNChars=%u), "
|
2012-03-09 04:27:51 +00:00
|
|
|
"mCompositionState=%s",
|
2014-11-10 09:07:43 +00:00
|
|
|
this, aContext, aOffset, aNChars, GetCompositionStateName()));
|
2010-03-24 15:04:39 +00:00
|
|
|
|
|
|
|
if (!mLastFocusedWindow) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(), FAILED, there are no focused window "
|
2015-07-26 23:23:04 +00:00
|
|
|
"in this module",
|
|
|
|
this));
|
2010-03-24 15:04:39 +00:00
|
|
|
return NS_ERROR_NULL_POINTER;
|
|
|
|
}
|
|
|
|
|
2012-06-03 03:27:48 +00:00
|
|
|
if (!aNChars) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(), FAILED, aNChars must not be zero", this));
|
2012-06-03 03:27:48 +00:00
|
|
|
return NS_ERROR_INVALID_ARG;
|
|
|
|
}
|
|
|
|
|
2015-10-18 05:24:48 +00:00
|
|
|
RefPtr<nsWindow> lastFocusedWindow(mLastFocusedWindow);
|
2010-03-24 15:04:39 +00:00
|
|
|
nsEventStatus status;
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2012-03-09 04:27:51 +00:00
|
|
|
// First, we should cancel current composition because editor cannot
|
|
|
|
// handle changing selection and deleting text.
|
2012-08-22 15:56:38 +00:00
|
|
|
uint32_t selOffset;
|
2012-03-09 04:27:51 +00:00
|
|
|
bool wasComposing = IsComposing();
|
|
|
|
bool editorHadCompositionString = EditorHasCompositionString();
|
|
|
|
if (wasComposing) {
|
|
|
|
selOffset = mCompositionStart;
|
2017-06-27 09:46:08 +00:00
|
|
|
if (!DispatchCompositionCommitEvent(aContext,
|
|
|
|
&mSelectedStringRemovedByComposition)) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(), FAILED, quitting from DeletText", this));
|
2012-03-09 04:27:51 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
} else {
|
2015-06-11 10:50:15 +00:00
|
|
|
if (NS_WARN_IF(!EnsureToCacheSelection())) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(), FAILED, due to no valid selection "
|
2015-07-26 23:23:04 +00:00
|
|
|
"information",
|
|
|
|
this));
|
2015-06-11 10:50:15 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
2012-03-09 04:27:51 +00:00
|
|
|
}
|
2015-06-11 10:50:15 +00:00
|
|
|
selOffset = mSelection.mOffset;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2010-03-24 15:04:39 +00:00
|
|
|
|
2012-06-03 03:27:48 +00:00
|
|
|
// Get all text contents of the focused editor
|
2015-09-10 01:40:05 +00:00
|
|
|
WidgetQueryContentEvent queryTextContentEvent(true, eQueryTextContent,
|
2013-10-01 07:23:00 +00:00
|
|
|
mLastFocusedWindow);
|
2012-09-28 06:57:33 +00:00
|
|
|
queryTextContentEvent.InitForQueryTextContent(0, UINT32_MAX);
|
2012-06-03 03:27:48 +00:00
|
|
|
mLastFocusedWindow->DispatchEvent(&queryTextContentEvent, status);
|
|
|
|
NS_ENSURE_TRUE(queryTextContentEvent.mSucceeded, NS_ERROR_FAILURE);
|
|
|
|
if (queryTextContentEvent.mReply.mString.IsEmpty()) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(), FAILED, there is no contents", this));
|
2012-06-03 03:27:48 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_ConvertUTF16toUTF8 utf8Str(
|
|
|
|
nsDependentSubstring(queryTextContentEvent.mReply.mString, 0, selOffset));
|
|
|
|
glong offsetInUTF8Characters =
|
|
|
|
g_utf8_strlen(utf8Str.get(), utf8Str.Length()) + aOffset;
|
|
|
|
if (offsetInUTF8Characters < 0) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(), FAILED, aOffset is too small for "
|
2016-12-16 03:16:31 +00:00
|
|
|
"current cursor pos (computed offset: %ld)",
|
2015-07-26 23:23:04 +00:00
|
|
|
this, offsetInUTF8Characters));
|
2012-06-03 03:27:48 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
|
|
|
AppendUTF16toUTF8(
|
|
|
|
nsDependentSubstring(queryTextContentEvent.mReply.mString, selOffset),
|
|
|
|
utf8Str);
|
|
|
|
glong countOfCharactersInUTF8 =
|
|
|
|
g_utf8_strlen(utf8Str.get(), utf8Str.Length());
|
|
|
|
glong endInUTF8Characters = offsetInUTF8Characters + aNChars;
|
|
|
|
if (countOfCharactersInUTF8 < endInUTF8Characters) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(), FAILED, aNChars is too large for "
|
2016-12-16 03:16:31 +00:00
|
|
|
"current contents (content length: %ld, computed end offset: %ld)",
|
2015-07-26 23:23:04 +00:00
|
|
|
this, countOfCharactersInUTF8, endInUTF8Characters));
|
2012-06-03 03:27:48 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
|
|
|
gchar* charAtOffset =
|
|
|
|
g_utf8_offset_to_pointer(utf8Str.get(), offsetInUTF8Characters);
|
|
|
|
gchar* charAtEnd =
|
|
|
|
g_utf8_offset_to_pointer(utf8Str.get(), endInUTF8Characters);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2010-03-24 15:04:39 +00:00
|
|
|
// Set selection to delete
|
2015-09-08 14:33:38 +00:00
|
|
|
WidgetSelectionEvent selectionEvent(true, eSetSelection, mLastFocusedWindow);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2012-06-03 03:27:48 +00:00
|
|
|
nsDependentCSubstring utf8StrBeforeOffset(utf8Str, 0,
|
|
|
|
charAtOffset - utf8Str.get());
|
|
|
|
selectionEvent.mOffset = NS_ConvertUTF8toUTF16(utf8StrBeforeOffset).Length();
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2012-06-03 03:27:48 +00:00
|
|
|
nsDependentCSubstring utf8DeletingStr(utf8Str, utf8StrBeforeOffset.Length(),
|
|
|
|
charAtEnd - charAtOffset);
|
|
|
|
selectionEvent.mLength = NS_ConvertUTF8toUTF16(utf8DeletingStr).Length();
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2011-10-03 07:56:21 +00:00
|
|
|
selectionEvent.mReversed = false;
|
|
|
|
selectionEvent.mExpandToClusterBoundary = false;
|
2012-03-09 04:27:51 +00:00
|
|
|
lastFocusedWindow->DispatchEvent(&selectionEvent, status);
|
2018-11-30 10:46:48 +00:00
|
|
|
|
2012-03-09 04:27:51 +00:00
|
|
|
if (!selectionEvent.mSucceeded || lastFocusedWindow != mLastFocusedWindow ||
|
|
|
|
lastFocusedWindow->Destroyed()) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(), FAILED, setting selection caused "
|
2015-07-26 23:23:04 +00:00
|
|
|
"focus change or window destroyed",
|
|
|
|
this));
|
2012-03-09 04:27:51 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
2010-03-24 15:04:39 +00:00
|
|
|
|
2018-02-22 11:56:08 +00:00
|
|
|
// If this deleting text caused by a key press, we need to dispatch
|
|
|
|
// eKeyDown or eKeyUp before dispatching eContentCommandDelete event.
|
Bug 1444572 - IMContextWrapper should dispatch fake eKeyDown event during composition if active IM is uim r=m_kato
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
2018-03-12 06:41:39 +00:00
|
|
|
if (!MaybeDispatchKeyEventAsProcessedByIME(eContentCommandDelete)) {
|
2018-02-22 11:56:08 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Warning,
|
|
|
|
("0x%p DeleteText(), Warning, "
|
|
|
|
"MaybeDispatchKeyEventAsProcessedByIME() returned false",
|
|
|
|
this));
|
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
2010-03-24 15:04:39 +00:00
|
|
|
// Delete the selection
|
2015-09-10 16:59:52 +00:00
|
|
|
WidgetContentCommandEvent contentCommandEvent(true, eContentCommandDelete,
|
2013-09-27 06:20:54 +00:00
|
|
|
mLastFocusedWindow);
|
2010-03-24 15:04:39 +00:00
|
|
|
mLastFocusedWindow->DispatchEvent(&contentCommandEvent, status);
|
2012-03-09 04:27:51 +00:00
|
|
|
|
|
|
|
if (!contentCommandEvent.mSucceeded ||
|
|
|
|
lastFocusedWindow != mLastFocusedWindow ||
|
|
|
|
lastFocusedWindow->Destroyed()) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(), FAILED, deleting the selection caused "
|
2015-07-26 23:23:04 +00:00
|
|
|
"focus change or window destroyed",
|
|
|
|
this));
|
2012-03-09 04:27:51 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!wasComposing) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Restore the composition at new caret position.
|
2014-11-10 09:07:43 +00:00
|
|
|
if (!DispatchCompositionStart(aContext)) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(), FAILED, resterting composition start", this));
|
2012-03-09 04:27:51 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!editorHadCompositionString) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsAutoString compositionString;
|
2014-11-10 09:07:43 +00:00
|
|
|
GetCompositionString(aContext, compositionString);
|
|
|
|
if (!DispatchCompositionChangeEvent(aContext, compositionString)) {
|
2015-07-26 23:23:04 +00:00
|
|
|
MOZ_LOG(
|
|
|
|
gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p DeleteText(), FAILED, restoring composition string", this));
|
2012-03-09 04:27:51 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
2010-03-24 15:04:39 +00:00
|
|
|
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::InitEvent(WidgetGUIEvent& aEvent) {
|
2016-03-28 04:29:42 +00:00
|
|
|
aEvent.mTime = PR_Now() / 1000;
|
2010-03-19 04:21:16 +00:00
|
|
|
}
|
2015-06-11 10:50:15 +00:00
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
bool IMContextWrapper::EnsureToCacheSelection(nsAString* aSelectedString) {
|
2015-06-11 10:50:15 +00:00
|
|
|
if (aSelectedString) {
|
|
|
|
aSelectedString->Truncate();
|
|
|
|
}
|
|
|
|
|
2017-06-27 09:46:08 +00:00
|
|
|
if (mSelection.IsValid()) {
|
|
|
|
if (aSelectedString) {
|
|
|
|
*aSelectedString = mSelection.mString;
|
2015-06-11 10:50:15 +00:00
|
|
|
}
|
|
|
|
return true;
|
2018-11-30 10:46:48 +00:00
|
|
|
}
|
2015-06-11 10:50:15 +00:00
|
|
|
|
|
|
|
if (NS_WARN_IF(!mLastFocusedWindow)) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p EnsureToCacheSelection(), FAILED, due to "
|
2016-07-05 09:44:18 +00:00
|
|
|
"no focused window",
|
|
|
|
this));
|
2015-06-11 10:50:15 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsEventStatus status;
|
2015-09-10 01:40:05 +00:00
|
|
|
WidgetQueryContentEvent selection(true, eQuerySelectedText,
|
2015-06-11 10:50:15 +00:00
|
|
|
mLastFocusedWindow);
|
|
|
|
InitEvent(selection);
|
|
|
|
mLastFocusedWindow->DispatchEvent(&selection, status);
|
|
|
|
if (NS_WARN_IF(!selection.mSucceeded)) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p EnsureToCacheSelection(), FAILED, due to "
|
2016-07-05 09:44:18 +00:00
|
|
|
"failure of query selection event",
|
|
|
|
this));
|
2015-06-11 10:50:15 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
mSelection.Assign(selection);
|
|
|
|
if (!mSelection.IsValid()) {
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Error,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p EnsureToCacheSelection(), FAILED, due to "
|
2016-07-05 09:44:18 +00:00
|
|
|
"failure of query selection event (invalid result)",
|
|
|
|
this));
|
2015-06-11 10:50:15 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!mSelection.Collapsed() && aSelectedString) {
|
|
|
|
aSelectedString->Assign(selection.mReply.mString);
|
|
|
|
}
|
|
|
|
|
|
|
|
MOZ_LOG(gGtkIMLog, LogLevel::Debug,
|
2016-07-06 09:52:23 +00:00
|
|
|
("0x%p EnsureToCacheSelection(), Succeeded, mSelection="
|
2017-06-27 09:46:08 +00:00
|
|
|
"{ mOffset=%u, Length()=%u, mWritingMode=%s }",
|
|
|
|
this, mSelection.mOffset, mSelection.Length(),
|
2016-07-05 09:44:18 +00:00
|
|
|
GetWritingModeName(mSelection.mWritingMode).get()));
|
2015-06-11 10:50:15 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/******************************************************************************
|
2015-07-26 23:23:04 +00:00
|
|
|
* IMContextWrapper::Selection
|
2015-06-11 10:50:15 +00:00
|
|
|
******************************************************************************/
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::Selection::Assign(
|
|
|
|
const IMENotification& aIMENotification) {
|
2015-06-11 10:50:15 +00:00
|
|
|
MOZ_ASSERT(aIMENotification.mMessage == NOTIFY_IME_OF_SELECTION_CHANGE);
|
2017-06-27 09:46:08 +00:00
|
|
|
mString = aIMENotification.mSelectionChangeData.String();
|
2015-06-11 10:50:15 +00:00
|
|
|
mOffset = aIMENotification.mSelectionChangeData.mOffset;
|
|
|
|
mWritingMode = aIMENotification.mSelectionChangeData.GetWritingMode();
|
|
|
|
}
|
|
|
|
|
2015-07-26 23:23:04 +00:00
|
|
|
void IMContextWrapper::Selection::Assign(
|
|
|
|
const WidgetQueryContentEvent& aEvent) {
|
2015-09-10 01:40:05 +00:00
|
|
|
MOZ_ASSERT(aEvent.mMessage == eQuerySelectedText);
|
2015-06-11 10:50:15 +00:00
|
|
|
MOZ_ASSERT(aEvent.mSucceeded);
|
2017-06-27 09:46:08 +00:00
|
|
|
mString = aEvent.mReply.mString.Length();
|
2015-06-11 10:50:15 +00:00
|
|
|
mOffset = aEvent.mReply.mOffset;
|
|
|
|
mWritingMode = aEvent.GetWritingMode();
|
|
|
|
}
|
2015-07-26 23:23:04 +00:00
|
|
|
|
|
|
|
} // namespace widget
|
|
|
|
} // namespace mozilla
|