Dropdown panel should not not be cut off when the editor is inside in an overflow: hidden host

[oleq]

ATM the dropdown recognizes the boundaries of the viewport and positions accordingly:

But it does not recognize the overflow: hidden ancestors and gets cut off, which is definitely annoying. It makes it impossible to use dropdown in the toolbar in modal windows if the dropdown is to be somewhere later in the toolbar (closer to the right edge).

[Reinmar]

Can it be easily moved to the document collection?

[oleq]

I created a similar PoC one day to solve some other issue (don't remember which one) and the biggest issue was that the panel must follow the toolbar when things are scrolled, etc. and there's was some positioning lag we decided was unacceptable.

Now I remember, I researched the horizontally scrollable toolbar for mobiles, gonna quote myself:

---

[...]

• To fight the above, I tried to rewrite dropdown panels to balloon–like components (with position: absolute + our positioning heuristics) and I found multiple issues with that approach:
  • The dropdowns were hit by the "position delay syndrome"
  • I found out our API is not ready for any UI component using BalloonPanelView or anything that goes into the "body" collection. ATM only plugins can use these things because to work with them, we need to know about the editor (EditorUI), which is impossible in plain UI components:
    • Where to insert it in DOM (editor.ui.view.body)
    • How to handle the focus (editor.ui.focusTracker)
  • Because of the above I had to rewrite createDrodpown so it gets both the reference to the body collection and the focus tracker so the dropdown can put the (now floating) panel in the right place in DOM and register it in the FC (the panel no longer belongs to the toolbar which is in the FC by default). That's quite a mess.
  • When the dropdown panel is no longer in the same tree as its button (in the "body" collection), when suddenly the toolbar changes its position (e.g. sticky panel is no longer sticky because of focus loss), we must update the position of the panel too. The dropdown has no idea what happens to the toolbar, it doesn't know anything about that (it's encapsulated as a View) so there's no way to tell the dropdown to update the position of its panel except from the outside. That would require a very weird API.

[Reinmar]

It's so sad. In other words – there's no viable solution at the moment. Not only we'd have to rewrite the dropdowns but also toolbars to use exactly the same positioning mechanism.

Am I right that the only solution, for now, is to not use overflow:hidden?

[oleq]

Not really. We can improve the panel positioning algorithm. It can detect not only the viewport boundaries but also ancestors with overflow: hidden. No changes to the DOM structures or toolbars.

[ghost]

Issue seems a bit old and closed, but I still have the problem. Should we reopen this one or generate a new ticket I don't know but only thing i can tell that the approach by trying to understand the overflow:hidden ancestors won't work. As my condition it didn't work, It have a grid, grid-item with overflow-hidden and a flex-box stretches the content. Solution should be applied on a bit more generic way. And I'm sure that it will be more easier than understanding the ancestors. Create an overlay element on top of everything. for example a div element with position static at the end of body and locate your dropdowns inside that according to the reference elements .getBoundingClientRect().top and left and of course width. Than you'll never fall in to dropdown crops.

[kvas-damian]

the same problem appears when CKEditor is rendered inside vertically scrollable container. For vertically scrollable container, browser cut/hide content that overlaps horizontally (similar to overflow-x: hidden but you cannot override it). Example: https://codepen.io/kvas-damian/pen/xxjEYXb