Incorrect selection behavior when inserting SVGs inside of an inline widget

[mabryl]

📝 Provide detailed reproduction steps (if any)

1. Create an inline widget plugin based on the Implementing an inline widget guide
2. Make the widget insert an SVG, for example, by using this code snippet:

const innerText = viewWriter.createRawElement( 'i', { id: 'foo-1234' }, function( domElement ) {
  domElement.innerHTML = `
    <svg fill="#000000" width="50px" height="50px" viewBox="-6.5 0 32 32" version="1.1" xmlns="http://www.w3.org/2000/svg">
      <path d="M9.281 9.688h2.406v2.406h-2.406v-2.406zM9.813 21.969l2.188 1.031-2.906 6.125-1.906-0.906z"></path>
    </svg>
  `;
} );

3. Build the editor with the plugin included
4. Try placing the selection after the inserted SVG

✔️ Expected result

The caret should appear to the right of the SVG, as is the case when inserting text via this method:

text.mov

❌ Actual result

You can't place the caret after the SVG. This example is from Google Chrome:

svg_chrome.mov

📃 Other details

• Browser: different browsers act differently in this case, see comment below for details
• OS: cross-OS
• First affected CKEditor version: N/A
• Installed CKEditor plugins: N/A

---

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

[mabryl]

As mentioned, this bug is different depending on the browser that you use. In Safari, you can place the selection after the widget but the caret is huge:

svg_safari.mov

[mabryl]

And Firefox acts similarly to Chrome:

svg_firefox.mov

[TerryCaliendo-WealthCounsel]

My temporary work-around is to add a tiny space after the svg.

const innerText = viewWriter.createRawElement( 'i', { id: 'foo-1234' }, function( domElement ) {
  domElement.innerHTML = `
    <svg fill="#000000" width="50px" height="50px" viewBox="-6.5 0 32 32" version="1.1" xmlns="http://www.w3.org/2000/svg">
      <path d="M9.281 9.688h2.406v2.406h-2.406v-2.406zM9.813 21.969l2.188 1.031-2.906 6.125-1.906-0.906z"></path>
    </svg>
    <span style="font-size: 1px">&nbsp</span>
  `;
} );

I've only tested it in Chrome and in my custom project. However, this work-around does seem to have an issues where the svg/widget will suddenly disappear after some actions in the editor, but I haven't yet found a way to consistently re-create the disappearance.

[Witoso]

@mabryl could you share more code? It's unclear whether 1) innerText is wrapped in some other element 2) which element is wrapped into toWidget method.

[TerryCaliendo-WealthCounsel]

I created a demo of how I discovered the issue in our custom configuration here:

https://www.dropbox.com/s/un3gw9cljb292k3/2023-06-12%2010-17-37.mkv?dl=0

[mabryl]

@Witoso sharing my project in a .zip below. You can just open the index.html file and it should work. Choosing any Placeholder from the dropdown menu should insert the SVG.

By the way, I'm not sure whether it's an issue limited to only SVGs (I'm guessing it's not) but for example <img> tags inserted by using this method worked correctly and didn't break the selection.

@TerryCaliendo-WealthCounsel many thanks for sharing the video here.

inline_svg.zip

[Witoso]

It may be related to some extent to us not supporting svg's (we treat it as an unsafe element AFAIK). Although it shouldn't matter for RawElements. We need to investigate it. Interesting that the keyboard navigation works fine.

[Witoso]

Long story short, browsers would like to place a caret in a text-like element, and the line ends without such. (similar to #12267). The scope of the fix would be to place an inline filler, the same one we place at the beginning of the line.

@TerryCaliendo-WealthCounsel for the workaround, instead of nbsp, try to use zws (​​/​​) for better behavior. I'm a bit worried about the situation where the svg/widget will suddenly disappear but the inserted space should not influence the editor in this way. Let us know when you observe this situation again.

We will add this to our bug-fixing queue.

[TerryCaliendo-WealthCounsel]

@Witoso - thanks for the update. I will try the Zero Width Space. The code is in our QE (Quality Engineer) process and I'm waiting to see if the have the "disappearing" issue. I saw it twice but haven't been able to recreate since.

[tyleregeto]

I am seeing this same behaviour with RawElement, and non SVG content. I've tried a variety of tags types that result in the same behaviour, such as span and a tags. Keyboard navigation works fine, but clicking always moves the cursor. If there is any text content after the raw element, there are no issues.

In my case, I was able to reproduce this with this minimal RawElement usage:

return writer.createRawElement('span', {}, (domElement) => {
    domElement.innerText = 'RawElement Content';
});

Video attached for reference.

rawelement.mp4

This video was taken in Chrome.

[Witoso]

I am seeing this same behaviour with RawElement

Citing the docs:

The raw elements work as data containers ("wrappers", "sandboxes") but their children are not managed or even recognized by the editor.

The best way is to pack the raw element into a widget in the editing view, and the behavior should work.