Skip to content
Snippets Groups Projects
  1. Mar 05, 2014
  2. Feb 28, 2014
  3. Feb 27, 2014
  4. Feb 26, 2014
  5. Feb 25, 2014
  6. Feb 24, 2014
  7. Feb 21, 2014
  8. Feb 20, 2014
    • Jean Chalard's avatar
      Change a heuristic and add a log. · 3b4c1d30
      Jean Chalard authored
      The heuristic in RichInputConnection makes little sense
      when textLength > mExpectedSelStart but we have
      more than 1024 characters of text. If there are that many,
      it's about 100% sure that 1024 is not the correct cursor
      position. With no good guess, we'll just continue trusting
      the app, even though we know it's lying : at least it will
      make the problem visible to the app author.
      
      Also, there have been a lot of confusion about initialSelStart
      and initialSelEnd. The keyboard should log them so that
      it helps us and editor authors debug more easily these
      common problems.
      
      Issue #65170 in AOSP and
      Bug: 12772035
      Change-Id: I6665a16c9f2832d33ee323f033bb38bcc092a3b4
      3b4c1d30
    • Jean Chalard's avatar
      Fix a bug where suggestions would not be updated. · 6f50c958
      Jean Chalard authored
      Also fix a small cosmetic bug where the suggestion strip
      would flash.
      
      Bug: 12951777
      Change-Id: I68b7bb9175571de9c718f737eebd9f67ea04a931
      6f50c958
    • Jean Chalard's avatar
      Don't distrust the cursor pos so much as to bug on IPC delay · 3c84eb88
      Jean Chalard authored
      When the cursor is moved by the user, the RichInputConnection
      is told about it. However, to work around a framework bug, it
      also looks at how many characters are in the buffer before the
      cursor, and if that's more than the value it's been passed, it
      deduces that's a framework bug and there are at least as many
      characters as seen before the cursor, so it puts the expected
      cursor position there.
      
      When you move the cursor, TextView calls onUpdateSelection,
      and when you move it fast, you'll get rapid-fire calls to
      onUpdateSelection. This is fine, the RIC is equipped to
      deal with that.
      
      However, these calls take some time to make it to the IME. In
      this instance, when the first call gets through and the IME
      calls TextView (synchronously) for text before the cursor, the
      cursor has already moved in the app, and TextView returns more
      characters than the cursor position was declared to be in this
      instance, so the RIC sets that as the expected cursor position.
      Sure enough, a split second later, the second call to
      onUpdateSelection arrives, with the new cursor position set
      where the RIC had found it too early. The RIC takes that as an
      "expected" cursor move, and the input does not get reset.
      
      Luckily, we have a way out. As far as we know, the framework bug
      only manifests itself upon rotation, which means we should only
      have to adjust for it in onStartInputView. Doing it in
      onUpdateSelection is too zealous (and probably too distrustful of
      the app to send the correct cursor positions).
      
      So we should just take care of the rotation case (by calling
      tryFixLyingCursorPosition in onStartInputView) and remove the
      compensating code in resetCachesUponCursorMoves.
      
      Bug: 12982502
      Change-Id: Ic3c1408a1ec45deaea63b01d98376a79ae567d77
      3c84eb88
    • Keisuke Kuroyanagi's avatar
      Add test only methods to test personalized dicts. · d36328ce
      Keisuke Kuroyanagi authored
      Bug: 11122480
      Change-Id: I79a4a73ff09a2d34d4ca094d705e901fb4bc855c
      d36328ce
Loading