Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
oleq opened this issue Jul 1, 2019 · 7 comments · May be fixed by ckeditor/ckeditor5-utils#293
Labels
package:ui support:2 An issue reported by a commercially licensed client. type:bug This issue reports a buggy (incorrect) behavior.

Comments

@oleq
Copy link
Member

oleq commented Jul 1, 2019

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

image

image

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).

image

@Reinmar
Copy link
Member

Reinmar commented Jul 1, 2019

Can it be easily moved to the document collection?

@oleq
Copy link
Member Author

oleq commented Jul 1, 2019

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" kapture 2018-10-15 at 13 10 45
    • 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.
      image
      image

@Reinmar
Copy link
Member

Reinmar commented Jul 2, 2019

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
Copy link
Member Author

oleq commented Jul 3, 2019

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.

@mlewand mlewand transferred this issue from ckeditor/ckeditor5-ui Oct 9, 2019
@mlewand mlewand added this to the backlog milestone Oct 9, 2019
@mlewand mlewand added status:confirmed support:2 An issue reported by a commercially licensed client. type:bug This issue reports a buggy (incorrect) behavior. package:ui labels Oct 9, 2019
@ghost
Copy link

ghost commented Jul 20, 2021

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.

@pomek pomek removed this from the backlog milestone Feb 21, 2022
@kvas-damian
Copy link

kvas-damian commented Sep 13, 2022

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

@ikhidebright
Copy link

This is still an issue, its sad

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:ui support:2 An issue reported by a commercially licensed client. type:bug This issue reports a buggy (incorrect) behavior.
Projects
None yet
6 participants