Aleksander Nowodzinski

@Mgsy Do you know where this issue originally came from?

It's definitely on my to-do list. I'll let you know when it's ready.

And what is the limiter here?

https://github.com/ckeditor/ckeditor5-ui/issues/173 should resolve it. Precisely: > Additionally getOptimalPosition() could check all the ancestors of the limiter which have overflow different than visible and intersect all their rects one by one...

That's exactly what I quoted ;-) `getOptimalPosition()` will essentially traverse up to the root of the document to check if the limiter isn't restricted by some `overflow: *` and if...

For the record, this issue is actually more complex than https://github.com/ckeditor/ckeditor5-utils/issues/148 and not covered by the fix. It is complex because: 1. As `#editable` is the `limiter`, there's no way...

> Besides, there's one more important problem – the scrolling is captured and blocked by the balloon which makes for a terrible UX. I don't think that it's easy to...

The issue came back to us in the document editor, which implements a scrollable editable by default. It's time we did something about that. 

The issue also appears when h–scrolling some wide content 

[This is a known bug in iOS](https://stackoverflow.com/questions/19245658/text-insertion-cursor-caret-appears-above-other-elements-in-mobile-browser). The only way to address this is by blurring the text field the selection is rendered in. @ckeditor/qa-team  Can you confirm this happens...