Typing accent marks on physical keyboards no longer works as of Gboard 6 |
||||
Issue descriptionGboard 5.2.0: working Gboard 6.0.65: exhibits bug What steps will reproduce the problem? (1) Set up a physical keyboard and set your language to Spanish (using Gboard as the keyboard) (2) Go to editpad.org (3) Type ' and then a What is the expected result? Should get รก What happens instead? Get 'a I think the problem is that we're depending on a composition to combine the accent with the letter. Comparing log output from Gboard 5 and Gboard 6, it looks like Gboard 6 made a change to call finishComposingText() after receiving the first key event (for the '), which breaks our accent handling, but not the system EditText widget's.
,
Sep 28 2017
>#c1 The current plan is to move physical accent mark handling out of ThreadedInputConnection and into Blink Is there way to handle in Clank side instead of Blink? We would like to reduce platform specific code in Blink.
,
Sep 28 2017
,
Sep 30 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5c5e2211ad9435a9c66072a0d0b5a2fbcaf6b552 commit 5c5e2211ad9435a9c66072a0d0b5a2fbcaf6b552 Author: Ryan Landay <rlanday@chromium.org> Date: Sat Sep 30 23:13:24 2017 Fix typing accent marks with physical keyboard and Gboard 6 Our current implementation of physical keyboard accent marks works by setting a composition on the accent mark when we receive a dead key, and replacing the composition range with the joined character when we receive a letter keypress that can be joined with the accent (or just committing the accent before handling the keypress if it's not joinable). Gboard 6 made a change causing it to balk upon seeing the composition and immediately call finishComposingText(), which makes it impossible to combine the accent with a letter. So our current implementation has been broken with every version of Gboard released in over a year. This CL changes the behavior to be more like on Windows, where nothing is shown for the dead key until the next character is typed. It's slightly different from the Windows behavior, because on Windows, typing an accent twice will actually output it twice, whereas in a native Android text box, typing an accent twice will only input it once. I am copying the Android behavior here as this is something people are likely to develop muscle memory around and I want to be consistent. I believe this approach is not ideal, and we should move the accent handling into Blink, and use a selection to join the accent, as happens in a native Android TextView. I would like to replace this solution with that one at some point if we come to the conclusion that it's safe to do so. Bug: 768981 Change-Id: I212098f9e31def2b08c37d0ac898eb4d5e738501 Reviewed-on: https://chromium-review.googlesource.com/687833 Reviewed-by: Alexandre Elias <aelias@chromium.org> Reviewed-by: Changwan Ryu <changwan@chromium.org> Commit-Queue: Ryan Landay <rlanday@chromium.org> Cr-Commit-Position: refs/heads/master@{#505470} [modify] https://crrev.com/5c5e2211ad9435a9c66072a0d0b5a2fbcaf6b552/content/public/android/java/src/org/chromium/content/browser/input/ThreadedInputConnection.java [modify] https://crrev.com/5c5e2211ad9435a9c66072a0d0b5a2fbcaf6b552/content/public/android/javatests/src/org/chromium/content/browser/input/ImeTest.java
,
Oct 5 2017
Will be fixed in M63. May come back and make the behavior feel more native and/or fix the keyup/keydown events at a later time.
,
Oct 5 2017
Verified fix in 63.0.3233.0 with physical keyboard settings to (Spanish) as default. |
||||
►
Sign in to add a comment |
||||
Comment 1 by rlanday@chromium.org
, Sep 27 2017