You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes, this behavior used to work in the previous version
The previous version in which this bug was not present was
No response
Description
This may sound familiar as it is a long known issue - but perhaps with a new suggestion how to fix it.
The autocomplete panel position is bound to body/html scroll events for performance reasons.
However adding cdkScrollable on a parent scrollable div can fix the issue (may result in performance loss/flickering).
But even if the autocomplete is in a scrollable scope the scrolling may lead to bad side effects (z-index, etc.): e.g. the demo for 15.0.0:
Since all other components (menu, select etc.) lock the scrolling of the body/underlaying scroll div, when opened - the same user experience for the autocomplete panel would be great.
Is this a regression?
The previous version in which this bug was not present was
No response
Description
This may sound familiar as it is a long known issue - but perhaps with a new suggestion how to fix it.
The autocomplete panel position is bound to body/html scroll events for performance reasons.
However adding
cdkScrollable
on a parent scrollable div can fix the issue (may result in performance loss/flickering).But even if the autocomplete is in a scrollable scope the scrolling may lead to bad side effects (z-index, etc.): e.g. the demo for 15.0.0:
Since all other components (menu, select etc.) lock the scrolling of the body/underlaying scroll div, when opened - the same user experience for the autocomplete panel would be great.
Reproduction
Steps to reproduce:
Expected Behavior
autocomplete should have a similar scrolling behaviour as other components
Actual Behavior
autocomplete does not prevent scrolling the underlying element
Environment
The text was updated successfully, but these errors were encountered: