diff options
| author | Yohei Yukawa <yukawa@google.com> | 2015-05-14 22:16:41 -0700 |
|---|---|---|
| committer | Yohei Yukawa <yukawa@google.com> | 2015-05-15 10:22:23 -0700 |
| commit | 5f05965f546fa42750f1a8314f8a2da01fd6bfb4 (patch) | |
| tree | c3da4fea37c7f1e179c0c73ec44e645191b9abcb /core/java/android/view/ViewRootImpl.java | |
| parent | 92847c968754f3fc2ffe849cf54ef6dd49b3e744 (diff) | |
| download | frameworks_base-5f05965f546fa42750f1a8314f8a2da01fd6bfb4.zip frameworks_base-5f05965f546fa42750f1a8314f8a2da01fd6bfb4.tar.gz frameworks_base-5f05965f546fa42750f1a8314f8a2da01fd6bfb4.tar.bz2 | |
Keep IMM#mCurRootView synchronized with the actual window focus.
Currently IMM#mCurRootView is always cleared every time when
IMM#finishInputLocked() is called. We have been doing this since
Iad09cf5dbb7f6f156fd39ed243431432e00f8945 so as not to hold the
strong reference to a DecorView so long time (Bug 6413553).
Strictly speaking, the attached window may continue holding
input focus even after IMM#finishInputLocked() is called.
In this state IMM#focusIn() might have unexpectedly rejected
focus-in event but presumably this might not be obvious, or might
not occur at all because in some situations IMM#finishInputLocked()
has never been called even when the attached view loses input
focus.
In order to fix Issue 20820914, however, we need to call
IMM#finishInputLocked() exactly when the attached view loses
input focus. To make it easier to diagnose any unexpected
regressions, this CL only changes the handling of
IMM#mCurRootView, while the next CL Id6afc8fc64512225578c62557b96
plumbs IMM#focusOut() to IMM#finishInputLocked().
Manually tested following scenarios.
- Repro steps in Bug 6413553. Made sure that IMM#mCurRootView
is cleared after switching back from the current application to
the previous application with back key.
- Test application that calls WebView#showFindDialog(). Made sure
that LatinIME works fine when switching text fields. This is
non-trivial because android.webkit.FindActionModeCallback is
changed in this CL.
- Repro steps in Bug 21144633. Made sure that we can enter
recipient's name in the messaging app.
Bug: 20820914
Change-Id: I219394178e4172bc47864297f1418e677dba25e5
Diffstat (limited to 'core/java/android/view/ViewRootImpl.java')
| -rw-r--r-- | core/java/android/view/ViewRootImpl.java | 13 |
1 files changed, 6 insertions, 7 deletions
diff --git a/core/java/android/view/ViewRootImpl.java b/core/java/android/view/ViewRootImpl.java index 4f2a3fa..4743494 100644 --- a/core/java/android/view/ViewRootImpl.java +++ b/core/java/android/view/ViewRootImpl.java @@ -2015,8 +2015,8 @@ public final class ViewRootImpl implements ViewParent, mLastWasImTarget = imTarget; InputMethodManager imm = InputMethodManager.peekInstance(); if (imm != null && imTarget) { - imm.startGettingWindowFocus(mView); - imm.onWindowFocus(mView, mView.findFocus(), + imm.onPreWindowFocus(mView, true /* hasWindowFocus */); + imm.onPostWindowFocus(mView, mView.findFocus(), mWindowAttributes.softInputMode, !mHasHadWindowFocus, mWindowAttributes.flags); } @@ -3321,11 +3321,10 @@ public final class ViewRootImpl implements ViewParent, .mayUseInputMethod(mWindowAttributes.flags); InputMethodManager imm = InputMethodManager.peekInstance(); + if (imm != null && mLastWasImTarget && !isInLocalFocusMode()) { + imm.onPreWindowFocus(mView, hasWindowFocus); + } if (mView != null) { - if (hasWindowFocus && imm != null && mLastWasImTarget && - !isInLocalFocusMode()) { - imm.startGettingWindowFocus(mView); - } mAttachInfo.mKeyDispatchState.reset(); mView.dispatchWindowFocusChanged(hasWindowFocus); mAttachInfo.mTreeObserver.dispatchOnWindowFocusChange(hasWindowFocus); @@ -3335,7 +3334,7 @@ public final class ViewRootImpl implements ViewParent, // so all of the view state is set up correctly. if (hasWindowFocus) { if (imm != null && mLastWasImTarget && !isInLocalFocusMode()) { - imm.onWindowFocus(mView, mView.findFocus(), + imm.onPostWindowFocus(mView, mView.findFocus(), mWindowAttributes.softInputMode, !mHasHadWindowFocus, mWindowAttributes.flags); } |
