-
Notifications
You must be signed in to change notification settings - Fork 6k
Work around Samsung keyboard issue #12432
Conversation
Samsung's Korean keyboard has a bug where it always attempts to combine characters based on its internal state, ignoring if and when the cursor is moved programmatically. EG typing "ㄴㅇ" and then moving the cursor back to the front of the text and typing "ㄴ" again would result in "ㄴㅇㄴ", not "ㄴㄴㅇ". Fully restarting the IMM works around this because it flushes the keyboard's internal state and stops it from trying to incorrectly combine characters. However this also has some negative performance implications, so we don't want to apply this workaround in every case.
justinmc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for this fix, it has been such a pain 😭
I think this is a pretty reasonable compromise. I was afraid I might have ended up hacking something much more sketchy!
It's important to note that with this fix, Flutter will not be able to support Samsung's ability to reopen composing regions. This is the feature that Samsung added to their keyboard to cause this bug in the first place. I explained in detail what the feature is in flutter/flutter#29341 (comment). It strikes me as a subtle thing that many users won't notice, but we'll have to wait and see if it ends up being a big deal for Korean users.
| private void setTextInputEditingState(View view, TextInputChannel.TextEditState state) { | ||
| if (!mRestartInputPending && state.text.equals(mEditable.toString())) { | ||
| @VisibleForTesting void setTextInputEditingState(View view, TextInputChannel.TextEditState state) { | ||
| if (!restartAlwaysRequired && !mRestartInputPending && state.text.equals(mEditable.toString())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any cases where this will cause the IMM to restart besides tapping to move the cursor? I wonder if there are any optimizations we can make by not restarting in those cases if so. Not sure though, I'll have to play around with the device tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. From reading through the code and manually testing it out it looked like just tapping to move, but I'm not totally convinced that I'm seeing the whole situation here. @jason-simmons do you know?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The engine asks the IMM to restart input when the app switches to a new text editing client or when the app sends an update to editor state originating from the Dart side.
In the latter case it's possible that we could diff the current and new state and do something less expensive than a full restart if the diff is simple enough. But AFAIK this hasn't been noticeable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems fine to me as-is after playing around with it. I only see it restart when the user pastes into the input, but that may be necessary, and it shouldn't be a performance problem anyway.
|
I'll ask @jayoung-lee for an opinion on if the lack of capability to reopen composing regions is significant or not. |
justinmc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
After playing around with it, it seems to still work with the "reopening" feature! It seems identical to the native input now as far as I can tell. I tried it on an old unaffected Samsung device, and the behavior was the same as native on that device (no composing region reopening). When I tried it on the new affected Samsung device, the behavior was also the same as native, and composing reopening worked.
Seems perfect to me!
| private void setTextInputEditingState(View view, TextInputChannel.TextEditState state) { | ||
| if (!mRestartInputPending && state.text.equals(mEditable.toString())) { | ||
| @VisibleForTesting void setTextInputEditingState(View view, TextInputChannel.TextEditState state) { | ||
| if (!restartAlwaysRequired && !mRestartInputPending && state.text.equals(mEditable.toString())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems fine to me as-is after playing around with it. I only see it restart when the user pastes into the input, but that may be necessary, and it shouldn't be a performance problem anyway.
GaryQian
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM from my end. We should keep an eye out to see if that regression we saw shows itself again, but it looks like it may have been an artifact of a different version. Thanks!
|
I helped @justinmc play around with the new keyboard, and yes, it seemed to work perfectly fine! Please let me know if anything new comes up in the future, I will be more than happy to help you test it :) |
|
Thank you @jayoung-lee! |
…1318) git@github.com:flutter/engine.git/compare/0bfca375b3f5...efb7bf4 git log 0bfca37..efb7bf4 --no-merges --oneline 2019-09-25 mklim@google.com Work around Samsung keyboard issue (flutter/engine#12432) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC aaclarke@google.com on the revert to ensure that a human is aware of the problem. To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
|
Might this be related to flutter/flutter#41315 ? |
|
Included in the assembly of the Russian language! |
…utter#41318) git@github.com:flutter/engine.git/compare/0bfca375b3f5...efb7bf4 git log 0bfca37..efb7bf4 --no-merges --oneline 2019-09-25 mklim@google.com Work around Samsung keyboard issue (flutter/engine#12432) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC aaclarke@google.com on the revert to ensure that a human is aware of the problem. To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
Samsung's Korean keyboard has a bug where it always attempts to combine
characters based on its internal state, ignoring if and when the cursor
is moved programmatically. EG typing "ㄴㅇ" and then moving the cursor
back to the front of the text and typing "ㄴ" again would result in
"ㄴㅇㄴ", not "ㄴㄴㅇ".
Fully restarting the IMM works around this because it flushes the
keyboard's internal state and stops it from trying to incorrectly
combine characters. However this also has some negative performance
implications, so we only apply the workaround on Samsung devices set
to use Korean input.
This also effectively disables the feature on Samsung keyboards that
allowed users to re-open a composing region for previously typed
characters. See flutter/flutter#29341 (comment).
Fixes flutter/flutter#29341.