Unable to place the caret after a trailing inline image

[dtdesign]

📝 Provide detailed reproduction steps (if any)

1. Go to https://ckeditor.com/docs/ckeditor5/latest/features/images/images-overview.html
2. Remove everything after Warsaw’s coat of arms.
3. Try placing the caret after the inline image.

The issue is reproducible using Gboard, but other keyboard such as SwiftKey do work. However, the behavior is not optimal because the caret is invisible in SwiftKey.

https://github.com/ckeditor/ckeditor5/assets/208610/152b5b64-52de-471b-a372-534edf95b008

✔️ Expected result

The caret is placed behind the image and permits key strokes.

❌ Actual result

The inline image is highlighted and the image toolbar is presented to the user.

📃 Other details

• Browser: Chrome 114
• OS: Android 11
• First affected CKEditor version: Unknown
• Installed CKEditor plugins: Not relevant, official demo

---

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

[dtdesign]

This is even worse than I thought. The issue is reproducible in Firefox on Windows and macOS too, thus this will now affect even more users than before.

@Witoso Can you update the labels to reflect this or should I create another issue for this to properly track it?

[Witoso]

At the beginning I wanted to answer that this is how Firefox works, as I remember we try to be leave the default behavior as much as possible, but I noticed one interesting thing.

In Chrome on click after an inline image we insert no breaks, whereas in FF they don't appear. @niegowski does FF hijacks somehow our action?

[niegowski]

I checked it in older docs and can see that this bug has been with us for a long time. The inline filler (7 x nobreak character) is inserted in places where the browser can't keep the selection so this text node is forcing the browser to anchor the selection in that node. As I checked an inline filler is properly inserted while moving caret with the keyboard arrow keys. The problem is that while clicking with the mouse, the inline filler is not yet there (also in all other browsers), and in firefox it does not even try to put a selection in that place.

[dtdesign]

[…] and in firefox it does not even try to put a selection in that place.

A few thoughts of mine, please feel free to disregard them:

• The issue appears to only affect both browsers when an inline image is the last element of the document.
• It might even occur when its the very first element of the document, I have not verified this.
• The click event provides the information about where the user intended to place the caret.
• When the result of the selection is to mark the inline image as active you could run a check:
  • event.target should be within the widget.
  • If it is not: Check the image’s getBoundingClientRect() and compare it to clientX/clientY of the DOM event.
  • Check if the image is the document’s first/last element and the click occurred nearby.

This is a rather dirty hack, but you are no longer reliant on the misguidance provided by the browser. Since this appears to be an isolated issue, this could be implemented as some sort of a “post click fixer” without requiring changes to the existing selection logic.

[niegowski]

I'd rather not suggest click handling by trying to find out the user's intention. There are some other issues with selection if the block ends with an inline widget (for example #12267). Different problems with DOM selection happen in different browsers. I think that most such cases could be fixed by using multiple inline fillers that would persist in the editing view around inline widgets (but maybe also block widgets because there are also issues with such cases).

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.