Bug 1523635 - part 1: Rename `maybeHandledAsynchronously` to `probablyHandledAsynchronously` r=m_kato
authorMasayuki Nakano <masayuki@d-toybox.com>
Tue, 05 Feb 2019 06:48:08 +0000
changeset 517655 f88aad0717142cb138669a7f9821a501818be757
parent 517654 25625eaa999ddda63b19f0f29c68026ac68c02f7
child 517656 2c8433c4b3f1fd7fd68decbff155511d70b997f2
push id2032
push userffxbld-merge
push dateMon, 13 May 2019 09:36:57 +0000
treeherdermozilla-release@455c1065dcbe [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersm_kato
bugs1523635
milestone67.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
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
widget/gtk/IMContextWrapper.cpp
--- a/widget/gtk/IMContextWrapper.cpp
+++ b/widget/gtk/IMContextWrapper.cpp
@@ -819,29 +819,29 @@ KeyHandlingState IMContextWrapper::OnKey
   // supports complicated composition like CJK IME.
   bool isDeadKey =
       KeymapWrapper::ComputeDOMKeyNameIndex(aEvent) == KEY_NAME_INDEX_Dead;
   mMaybeInDeadKeySequence |= isDeadKey;
 
   // 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.
-  bool maybeHandledAsynchronously =
+  bool probablyHandledAsynchronously =
       mIsIMInAsyncKeyHandlingMode && currentContext == mContext;
 
   // If we've decided that the event won't be synthesized asyncrhonously
   // by IME, but actually IME did it, this is set to true.
   bool isUnexpectedAsyncEvent = false;
 
   // 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
   // flag because it's difficult to store all pending key events by
   // an array or a hashtable.
-  if (maybeHandledAsynchronously) {
+  if (probablyHandledAsynchronously) {
     switch (mIMContextID) {
       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.
         bool isHandlingAsyncEvent = !!(aEvent->state & IBUS_IGNORED_MASK);
@@ -861,17 +861,17 @@ KeyHandlingState IMContextWrapper::OnKey
                      "same event in the queue.  So, assuming it's a "
                      "synthesized event",
                      this));
           }
         }
 
         // ibus won't send back key press events in a dead key sequcne.
         if (mMaybeInDeadKeySequence && aEvent->type == GDK_KEY_PRESS) {
-          maybeHandledAsynchronously = false;
+          probablyHandledAsynchronously = false;
           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.
@@ -879,30 +879,30 @@ KeyHandlingState IMContextWrapper::OnKey
               !aEvent->hardware_keycode) {
             isUnexpectedAsyncEvent = true;
             break;
           }
         }
         // ibus handles key events synchronously if focused editor is
         // <input type="password"> or |ime-mode: disabled;|.
         if (mInputContext.mIMEState.mEnabled == IMEState::PASSWORD) {
-          maybeHandledAsynchronously = false;
+          probablyHandledAsynchronously = false;
           isUnexpectedAsyncEvent = isHandlingAsyncEvent;
           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));
-          maybeHandledAsynchronously = false;
+          probablyHandledAsynchronously = false;
           mPostingKeyEvents.RemoveEvent(aEvent);
           break;
         }
         break;
       }
       case IMContextID::eFcitx: {
         // See src/lib/fcitx-utils/keysym.h
         static const guint FcitxKeyState_IgnoredMask = 1 << 25;
@@ -928,17 +928,17 @@ KeyHandlingState IMContextWrapper::OnKey
                      "but same event in the queue.  So, assuming it's a "
                      "synthesized event",
                      this));
           }
         }
 
         // fcitx won't send back key press events in a dead key sequcne.
         if (mMaybeInDeadKeySequence && aEvent->type == GDK_KEY_PRESS) {
-          maybeHandledAsynchronously = false;
+          probablyHandledAsynchronously = false;
           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.
@@ -955,17 +955,17 @@ KeyHandlingState IMContextWrapper::OnKey
         if (isHandlingAsyncEvent) {
           MOZ_LOG(gGtkIMLog, LogLevel::Info,
                   ("0x%p   OnKeyEvent(), aEvent->state has "
                    "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",
                    this));
-          maybeHandledAsynchronously = false;
+          probablyHandledAsynchronously = false;
           mPostingKeyEvents.RemoveEvent(aEvent);
           break;
         }
         break;
       }
       default:
         MOZ_ASSERT_UNREACHABLE(
             "IME may handle key event "
@@ -984,17 +984,17 @@ KeyHandlingState IMContextWrapper::OnKey
     // 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.
   }
   mFallbackToKeyEvent = false;
   mProcessingKeyEvent = aEvent;
   gboolean isFiltered = gtk_im_context_filter_keypress(currentContext, aEvent);
   if (aEvent->type == GDK_KEY_PRESS) {
-    if (isFiltered && maybeHandledAsynchronously) {
+    if (isFiltered && probablyHandledAsynchronously) {
       sWaitingSynthesizedKeyPressHardwareKeyCode = aEvent->hardware_keycode;
     } else {
       sWaitingSynthesizedKeyPressHardwareKeyCode = 0;
     }
   }
 
   // The caller of this shouldn't handle aEvent anymore if we've dispatched
   // composition events or modified content with other events.
@@ -1018,17 +1018,17 @@ KeyHandlingState IMContextWrapper::OnKey
     // but we should dispatch keydown event as
     filterThisEvent = false;
   }
 
   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.
-    if (!maybeHandledAsynchronously) {
+    if (!probablyHandledAsynchronously) {
       MaybeDispatchKeyEventAsProcessedByIME(eVoidEvent);
       // Be aware, the widget might have been gone here.
     }
     // 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.
@@ -1048,21 +1048,21 @@ KeyHandlingState IMContextWrapper::OnKey
     // GDK_KEY_RELEASE since it may not be filtered by active keyboard
     // layout even in composition.
     mMaybeInDeadKeySequence = false;
   }
 
   MOZ_LOG(gGtkIMLog, LogLevel::Debug,
           ("0x%p   OnKeyEvent(), succeeded, filterThisEvent=%s "
            "(isFiltered=%s, mFallbackToKeyEvent=%s, "
-           "maybeHandledAsynchronously=%s), mPostingKeyEvents.Length()=%zu, "
+           "probablyHandledAsynchronously=%s), mPostingKeyEvents.Length()=%zu, "
            "mCompositionState=%s, mMaybeInDeadKeySequence=%s, "
            "mKeyboardEventWasDispatched=%s, mKeyboardEventWasConsumed=%s",
            this, ToChar(filterThisEvent), ToChar(isFiltered),
-           ToChar(mFallbackToKeyEvent), ToChar(maybeHandledAsynchronously),
+           ToChar(mFallbackToKeyEvent), ToChar(probablyHandledAsynchronously),
            mPostingKeyEvents.Length(), GetCompositionStateName(),
            ToChar(mMaybeInDeadKeySequence), ToChar(mKeyboardEventWasDispatched),
            ToChar(mKeyboardEventWasConsumed)));
 
   if (filterThisEvent) {
     return KeyHandlingState::eHandled;
   }
   // If another call of this method has already dispatched eKeyDown event,