Skip to content
Commit 5f05965f authored by Yohei Yukawa's avatar Yohei Yukawa
Browse files

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
parent 92847c96
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment