recogito/recogito-client-core

Editor position overflow detection

kdaniel21 opened this issue · 2 comments

Hi, sorry, but it's us again! :)
We've discovered that when having the annotateable text around the middle of the window, the popup/dropdown/editor is often opening in positions where it overflows its parent, as it's visible in my screenshot. This behavior does not appear when the popup/dropdown/editor would overflow the entire window, in those cases it correctly opens to the other side.

The above observation seems to have been confirmed by the source code as well. I'm far from being familiar with the codebase, still, as far as I could see the relevant lines are in setPosition.js:21, where the positioning is done, preventing it from overflowing the window. I'm wondering whether we're doing something wrong, or whether there's an extra way to make it consider its parent element instead of the window.

I've only found a single issue with similar problems, yet, I couldn't figure out what a CSS solution could look like, given that the editor/dropdown/popup element is deeply nested, so no amount of z-index hacking would work here.

Thank you for taking the time and helping us out!

Ah yes, good point. The popup will indeed use window bounds for orientation.

Depends on what you want the popup behavior to look like (and what your page markup structure is):

  • if the annotateable area is an iframe, I think there might be nothing you can do, without a change to setPosition
  • if your annotateable area is a DIV, it might have its overflow CSS property set to hidden. If you try forcing it to overflow: visible and add a high z-index, perhaps that might prevent the popup from being clipped?

If not, we'd need to change setPosition to use the parent element bounds, instead of window bounds, for positioning. But that would need to be made optional IMO, because it won't be desirable in all cases.

Ok, here's an update to this: Editor auto-position now respects iframe bounds. That means the Editor will always attempt to stay inside the iframe, in the same way it attempts to stay inside the window.

The Editor will, by design, ignore any other container element (DIV) as far as auto-positioning goes, since it should generally be acceptable/desirable to let the Editor extend over the bounds of the container element. (You just need to make sure the container element doesn't have its CSS overflow property set to hidden.)

I'm not ruling out a config setting that restricts the editor auto-position to the bounds of the container element. But, at least, this won't happen with the next release. (Therefore I'm keeping the issue open.)