New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 771263 link

Starred by 0 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Odd editing behavior on Android with certain markup including empty element when using Swype keyboard

Project Member Reported by rlanday@chromium.org, Oct 3 2017

Issue description

Chrome Version: 63.0.3231
OS: (e.g. Win7, OSX 10.9.5, etc...)

What steps will reproduce the problem?
(1) adb push the attached file (a_insert_bug_3.html) to an Android device running Swype.
(2) Long press the word "test" (do not choose "Select All")
(3) Type a letter on the Swype keyboard.

What is the expected result?

The typed letter should replace the text.

What happens instead?

A capital letter "J" replaces the text. Continuing to type replaces the letter J.

For convenience, this is what the buggy markup looks like:

<div contenteditable="true"><img />test</div> 
 
a_insert_bug_3.html
66 bytes View Download
Bisects to:

Remove selected text when committing empty text
https://codereview.chromium.org/2874783004
I don't think the bisect CL is really the root cause here. I think it just corrects our behavior in a way that exposes another issue.

The J is coming from Swype autocorrect. I figured this out by selecting the last four letters of "Atest" and typing a character to replace the word with. The invisible object replacement character corresponding to the <img> is confusing Swype and making it think we're in the middle of a word.

I think we shouldn't send the object replacement character to the IME. It is not necessary for properly determining the selection, since I think VisiblePosition normalization means at most one of the positions immediately before or after the <img> will be considered valid.
Cc: changwan@chromium.org
Note: the J is not necessarily consistent, because Swype learns words, and keyboard autocorrect in general is usually not reproducible between runs. That made this somewhat frustrating to figure out.
Cc: aelias@chromium.org
Without the object replacement character, there is no way for the user to delete/replace the image. Since object replacement character is a unicode spec, I tend to think that swype can do a better job. Did you check other keyboards' behavior?
Hmm I think you're right. The case where the image has no src and doesn't render is kind of pathological, but they have the same bug where there actually is an image you can obviously select. I'll file a bug on them.

Gboard and Samsung's keyboard don't run into this issue, but I suspect it's because they don't have this interesting behavior of trying to autocorrect a word after you select half of it and type a new character vs. them actually implementing behavior to handle the object replacement character specifically.
Labels: -Pri-2 Pri-3
Status: ExternalDependency (was: Assigned)
To clarify, it's necessary to emit the object replacement character for an image so you can delete it by moving the insertion point immediately after it and pressing "delete" on the virtual keyboard. The image needs to correspond to a character in the text given to the IME for this to work properly.
Owner: ----
Status: WontFix (was: ExternalDependency)
Swype has been discontinued so this is never going to get fixed (unless we decide to change our implementation for some reason):

https://www.xda-developers.com/swype-keyboard-android-dragon-dictation-discontinued/

Sign in to add a comment