Text alternative leaks to the browser's window after pasting a lot of content to the balloon

[Mgsy]

🐞 Is this a bug report or feature request? (choose one)

• Bug report

💻 Version of CKEditor

1.0.0-alpha2

📋 Steps to reproduce

1. Go to http://localhost:8125/ckeditor5-core/tests/manual/article.html.
2. Focus the editor and press Ctrl + A.
3. Press Ctrl + C.
4. Open the text alternative balloon.
5. Focus the input.
6. Hold Ctrl + V for few seconds.
7. Press Save.

✅ Expected result

Text alternative is visible only inside the balloon's input.

❎ Actual result

Some part of the text alternative has appeared at the top of the browser

📃 Other details that might be useful

Notes

• It appears on every image focus
• If you click on the text, editor will crash with the error:

utils.js:36 Uncaught TypeError: Cannot read property 'getCustomProperty' of undefined
   at isWidget (utils.js:36)
   at Widget._onMousedown (widget.js:115)
   at Document.listenTo.args (widget.js:83)
   at Document.fire (emittermixin.js:269)
   at MouseObserver.fire (domeventobserver.js:96)
   at MouseObserver.onDomEvent (mouseobserver.js:29)
   at ProxyEmitter.listenTo (domeventobserver.js:79)
   at ProxyEmitter.fire (emittermixin.js:269)
   at HTMLDivElement.domListener (emittermixin.js:237)

GIF

Other information

OS: Windows 10, MacOS X
Browser: All browsers

[Reinmar]

WUT... So weird :D

[Reinmar]

cc @oleq

[oleq]

It's super weird but this is what happens:

0. When the widget is selected, some sort of a paste bin shows up containing the following content
   . Once the widget is blurred, the paste bin disappears.
1. Upon paste in the text alt input, the bin gets all the pasted content, which is weird. Is it by design? What's the purpose of that bin, BTW?
2. When the widget is re-selected, paste bin shows up in DOM again, with the same content it had after the paste. Which is also totally weird.
3. Because there's a looooot of text in the paste bin, -9999px is not enough to hide it off screen.

[Reinmar]

This is a so-called fake selection container. We need to use it to store the real selection when a widget is selected (because the browser would not allow selecting such elements).

However, it should never get any data. Especially not if another input is selected. It sounds like a browser bug.

OTOH, it's a complete edge case to paste that much content into a link URL input. It might only happen by accident, in fact.

As a kind of bulletproofing fake selection container's implementation we can add listeners to stuff like paste, drop, keydown in there and preventDefault() on them. Although, since it's not an editing host itself (the root editable is) we'd need to use the capturing phase.

[oleq]

Considering the above, I think the easiest (and the fastest) solution is limiting FSC's width. I checked and width: 42px works like a charm.