Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text suggestions on Android with adjacent spaces are broken #15831

Open
dtdesign opened this issue Feb 11, 2024 · 2 comments
Open

Text suggestions on Android with adjacent spaces are broken #15831

dtdesign opened this issue Feb 11, 2024 · 2 comments
Labels
browser:android domain:typing/ime This issue reports a problem with standard typing & IME (typing method for CJK languages). package:typing type:bug This issue reports a buggy (incorrect) behavior.

Comments

@dtdesign
Copy link

📝 Provide detailed reproduction steps (if any)

The following uses the | character to denote the caret position.

  1. Type in Hello World, these are two spaces in the middle.
  2. Place the caret in between both spaces: Hello | World.
  3. Type in te which shows as Hello te| World in the editor.
  4. Click on the text suggestion for Test.
  5. Result: HelloTest | World.

✔️ Expected result

The typed in part te should be replaced with Test.

❌ Actual result

The word is inserted at an incorrect position.

❓ Possible solution

I have the strong suspicion that this is the result of a whitespace mismatch as outlined in my findings in both #14707 and #13994. This is not resolved by my workaround described in #13994 (comment) which is to be expected since it’s a rather defensive approach and only targets the end of the string.

Inspecting the DOM for Hello | World shows that the content is Hello\u0020|\u00a0World which means that to the left of the caret is a regular space which from my experience can throw off the composition replacement when the editor swaps it our for \u00a0. I can imagine that my workaround above can be adapted to cover this case too, possibly requiring a two-pass diff to first figure out the changes and then probe if the position of the change is similar, virtually ignoring the content to the right of the caret.

📃 Other details

  • Browser: Chrome and Firefox latest
  • OS: Android 14 (verified with both GBoard and Samsung Keyboard)
  • First affected CKEditor version: Unknown
  • Installed CKEditor plugins: Official demo

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

@dtdesign dtdesign added the type:bug This issue reports a buggy (incorrect) behavior. label Feb 11, 2024
@dtdesign
Copy link
Author

The effect is even worse with GBoard when there are only spaces and the caret is between them. For my illustration I will use to mark the caret position and to indicate \u00a0:

█⋮█
█T⋮█
█Te⋮█
(Now pick the suggestion for “Test")
█T st█⋮

I once again set up some logging in updateTextNode() (renderer.ts) to report the unmodified actualText and expectedText when it differs, but without any further processing. The only change is turning \u00a0 to for readability. These are the changes that reproducibly take place:

█ => ██ (via pendingChanges)
██ => █T█ (via pendingChanges)
█T█ => █Te█ (via pendingChanges)
(Now pick the suggestion for “Test")
█Te█ => █T█ (via pendingChanges)
█T█ => █T st█ (via pendingChanges)

While the changes are somewhat strange, it is notable that GBoard does not fire the composition events at all. There is obviously something wrong with what happens in the editor, but for once these are not the result of the DOM MutationObserver. However, this is running my modified version thus there is a much greater tolerance towards the types of spaces being present, so it could be there would be some additional changes back and forth. The result is the same as proven using the online demo of CKEditor though.

I then set up a logger in the insertText event handler in insert.ts:

(space)
(space)
T
e
(Now pick the suggestion for “Test")
st

Amazing. Let’s check what the Samsung Keyboard does for the insertText:

(space)
(space)
T
Te
Te (fires twice because … I don’t know, it just happen to does that)
Test

Could it be any worse? Not only does the keyboards behave wildly different, GBoard (by Google!) actually fundamentally differs to the assumptions made in #12446 about the behavior of compositions. On the bright side, GBoard does not fire the composition events so that information can be used to make a distinction?

@dtdesign
Copy link
Author

I did some little more testing to see if I can further narrow it down but it looks like there is no common solution due to the slightly different behavior of both keyboards.

Unfortunately, I have other important tasks to do and cannot justify investing more time at this point towards this issue. It simply is too time consuming for me to not only analyze an issue but at the same time teach myself on the inner workings of CKEditor to be able to find the spot where things break. If there is any more information I can provide then please feel free to ping me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
browser:android domain:typing/ime This issue reports a problem with standard typing & IME (typing method for CJK languages). package:typing type:bug This issue reports a buggy (incorrect) behavior.
Projects
None yet
Development

No branches or pull requests

2 participants