delete does not delete selected text in swype keyboard |
|||||||||
Issue descriptionThis report will ONLY be viewable by Google. Device name: Nexus 5, Huawei Honor 5x Android version: MOB31V, 6.0.1 Fingerprint: WebView version (from system settings -> Apps -> Android System WebView): 59.0.3068.1, 56.0.2904.0 Application: webview shell browser Application version: 1.0 URLs (if applicable): www.textarea.org Bisect Information (update as information becomes available): Culprit CL: https://chromium.googlesource.com/chromium/src/+/7c04b06d49b5554e9a24a32a4b964ca651212b34 Steps to reproduce: (1) Install swype trial keyboard from the play store, select it as input method (1) Visit www.textarea.org (2) Type some text (3) Select a word, press backspace Expected result: Word is deleted Actual result: Word not deleted, text remain highlighted with no handles Marking this as RBS for M58. Although issue is already in stable, it is a regression that affects users of swype.
,
Apr 11 2017
,
Apr 11 2017
Already in stable for 2 releases, so targeting it for M59.
,
Apr 14 2017
I think Swype keyboard was depending on Chrome's non-spec behavior to commit an empty string to delete the selection. But there is no mention of deleting the currently selected text in such a case in Android's InputConnection spec: https://developer.android.com/reference/android/view/inputmethod/InputConnection.html#setComposingText(java.lang.CharSequence, int) The previous commitText("") implementation was re-routed to setComposingText("") before yabinh@'s CL (https://codereview.chromium.org/2458773005) Also, I think we decided to keep this behavior recently to address Linux Japanese IBus issue: https://codereview.chromium.org/2458773005 In any case, we do not want to keep the incorrect behavior, so Swype developers should adapt to the new behavior and fix its app. I'll report this on Swype forums.
,
Apr 14 2017
Hmm.. Actually I verified that commitText("", 1) deletes the current selection for EditText using RemoteIME. Let me fix this.
,
Apr 25 2017
I realized that I need to fix CancelComposition() first because Autofill calls UnmarkText() function (which itself is also weird) and if I fix internal editing methods (Editor::InsertTextWithoutSendingTextEvent) for commitText() it gets affected. I need to untangle Autofill and UnmarkText() first.
,
May 10 2017
Issue 712451 has been merged into this issue.
,
May 11 2017
UnmarkText() -> CancelComposition() is fixed by someone else. I've uploaded https://codereview.chromium.org/2874783004/ for review.
,
May 12 2017
requesting merge of https://codereview.chromium.org/2874783004/ into m59
,
May 13 2017
Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 15 2017
merged as https://codereview.chromium.org/2883073002/
,
May 16 2017
Verified on Nexus 6 / N2G47S on Version M60: 60.0.3100.0 Thanks!
,
May 16 2017
,
May 18 2017
Verified this fix on M59:59.0.3971.60 on Galaxy Tab S2 (SM-T815Y) / NRD90M and Seed/NMF27E |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by aluo@chromium.org
, Apr 11 2017