Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit 42275bc8 authored by Yohei Yukawa's avatar Yohei Yukawa
Browse files

Fix a regression in InputMethodUtils.

It turns out that my previous CL [1] unexpectedly changed the behavior
of InputMethodUtils#getImplicitlyApplicableSubtypesLocked() in terms of
when "EnabledWhenDefaultIsNotAsciiCapable" extra value is taken into
account.

Suppose if an IME X has the following three subtypes:
 A. locale: en_US
    mode: handwriting
    extraValue:
 B. locale: hi
    mode: keyboard
    extraValue:
 C. locale: en_US
    mode: keyboard
    extraValue: AsciiCapable
 D. locale: zz
    mode: keyboard
    extraValue: AsciiCapable, EnabledWhenDefaultIsNotAsciiCapable

Given the above subtypes, here are results of what subtypes are enabled
by InputMethodUtils#getImplicitlyApplicableSubtypesLocked() I) before
the CL [1] and II) after the CL [1].

  - system language: hi:
      I:  B, D
     II:  B, D
  - system language: hi-IN:
      I:  B, D
     II:  B, D
  - system language: en-US
      I:  A, C
     II:  A, C
  - system language: en-GB
      I:  A, C
     II:  A, C
  - system language: ja-JP
      I:  B
     II:  D

What my previous CL actually broke is the the last one, and it's broken
because we accidentally started using
"EnabledWhenDefaultIsNotAsciiCapable" even when there is no subtype that
matches to the requested language.  Previously that attribute was used
if and only if 1) there is a subtype that matches the requested language
and 2) that subtype is not marked to be AsciiCapable.

If there there is no subtype that matches to the requested language,
what we had relied on is actually the result of
InputMethodUtils#findLastResortApplicableSubtypeLocked() called with
  canIgnoreLocaleAsLastResort = true,
which means that we had just picked up the first keyboard subtype as the
last fallback candidate regardless of it's locale.  This is why the
subtype B should be picked up in the last case where system language is
ja-JP.

This CL fixes the above unexpected behavior change regarding
"EnabledWhenDefaultIsNotAsciiCapable" so that the previous behavior can
be preserved.

  [1] Iaf179d60c12b9a98b4f097e2449471c4184e049b
      e985c240

Bug: 27129703
Bug: 27425459
Change-Id: Icd86cad955bf827a1eb41255f57fdf4ec315b93b
parent 25b86cca
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