A scrolling container leaves FloatPanels (dropdown menus, toolbars, tooltips) unmoored / positioned incorrectly
See original GitHub issueThis is both a bug report and a feature request.
Currently, if TinyMCE is the child of a container which scrolls, the menus and tooltips become unmoored. For example:
A <div>
with height: #px
and overflow: auto
→ jsbin
A <div>
with position: fixed
→ jsbin
I expect a mechanism for handling this scenario.
I’ve seen two possible solutions discussed.
Constraining the UI elements to a given container, as described
- How to change floatPanel’s parent?
- Dropdown panel is not properly affixed
- Adding settings option for container element
Monitoring DOM events to hide the pop-over elements when necessary, as described
- Tinymce-floatpanels can be in odd positions if editor is scrolled.
- How to affix dropdown list menu next to selected dropdown button when user scrolling?
Neither of these work as expected in fairly common edge cases. For example:
When using the first solution, content loaded into the scrolling container above TinyMCE can cause the FloatPanel position calculations to be incorrect.
When using the second solution, the sudden disapearance of menus may be poor UX. Also, certain overlays require hacks, like tooltips, or are even immune to tinymce.ui.FloatPanel.hideAll()
, like the table manipulation toolbar.
I’d like to propose a third solution. Repositioning the overlays when the element they’re supposed to be attached to moves. This desire is inspired by react-popover’s repositioning handling.
I don’t know how viable any proposed solution might be. Currently I’m using the second solution. I do think the options are worth discussing though.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:13
- Comments:32 (2 by maintainers)
I recently got it working using a combination of the changes suggested here. It seems the main problem is that I had the following in the css
After I removed this it started working.
It’s still an issue for TinyMCE 5