Popup remains visible when scrolling inside scrollview

Hello,

we noticed the following behavior when using Webix (tested also with the latest version 11.3):

If a suggest (e.g. text field with autocomplete) or a datepicker is opened inside a scrollview, and the user scrolls within that container, the popup remains visible.

The position is not recalculated and the popup becomes visually detached from its related input field.

This can be reproduced with the following minimal example:
https://snippet.webix.com/pa742pgy

Expected behavior:
When scrolling inside the container, the popup should either:

  • automatically close, or
  • reposition itself correctly.

Current behavior:
The popup remains visible and is no longer aligned with the input field.

Is this the intended behavior?
Are there any plans to improve this in future versions?

Thank you.

Hello,

Thanks for the report.

Currently, the popup (suggest) is positioned using position: absolute and only receives the initial position of the target, without updating it until the next show() call. The main issue of addressing this differently is watching for changes in every scrollable parent of the target (regardless of the complexity of the UI).

In our previous research, this brought a few side effects and added unwanted complexity into the popup lifecycle and related event handling. Due to this, the core logic is still simplified, but we will pass the information to our dev team for additional review.

In the meantime, you can use this workaround: Code Snippet

The scrollview is extended using the protoUI function. In the $init method, which is called before the view initializes, a scroll event listener is attached to the view. The popup is updated by calling the show method. During the update, the event handling for the popup itself is blocked to prevent resetting its internal state (e.g. selected month in date pickers). The popup also becomes hidden when the target input is out of view.

Here is an alternative, simpler workaround that hides (instead of moving) the popup/suggest on scroll: Code Snippet. The global click event hides all popups.

1 Like

Hello,

thank you for the detailed explanation. We understand the technical reasoning behind the current implementation and the complexity of tracking all scrollable parents in dynamic layouts. From a UX perspective, however, this behavior can lead to confusing situations, especially in enterprise applications where forms are often embedded inside nested scrollviews (e.g. edit windows, panels, sidebars, etc.). In such cases, the popup appearing visually detached from its input field may look like a rendering bug.

For our use case, automatically hiding the popup on scroll seems to be the safest and most predictable behavior. Repositioning would be ideal, but we agree that it introduces lifecycle complexity.

Thank you again for the clarification.