-
Notifications
You must be signed in to change notification settings - Fork 6.8k
fix(reposition-scroll-strategy): use last calculated position to re-align the overlay #5471
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
fix(reposition-scroll-strategy): use last calculated position to re-align the overlay #5471
Conversation
…lign the overlay Uses the element's last calculated position to re-align it, instead of recomputing the position completely. This prevents the overlay from jumping into the viewport when the user scrolls away.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems kind of weird to make this change to the OverlayRef and the GlobalPositionStrategy for something that only happens for the connected position strategy. Is there some way we could isolate the behavior to just that class, perhaps by providing it additional information?
Initially I did it with |
… connected overlay Currently when updating the position of an open connected overlay (e.g. when the user is scrolling) we go through the same process for determining the preferred position as when the overlay was attached. This means that the preferred position could change, causing the overlay to jump. With these changes the overlay will determine its preferred position when it's attached and the re-use the same position until it's detached. This is a prerequisite to moving the scroll clipping logic out of the `ConnectedPositionStrategy` and into the scroll strategies. This PR is a resubmit of angular#5471.
Closing in favor of #7805. |
…pplying to open connected overlay Currently when updating the position of an open connected overlay (e.g. when the user is scrolling) we go through the same process for determining the preferred position as when the overlay was attached. This means that the preferred position could change, causing the overlay to jump. With these changes the consumer can decide to lock an overlay into its initial position, preventing it from jumping. This PR is a resubmit of angular#5471.
…pplying to open connected overlay Currently when updating the position of an open connected overlay (e.g. when the user is scrolling) we go through the same process for determining the preferred position as when the overlay was attached. This means that the preferred position could change, causing the overlay to jump. With these changes the consumer can decide to lock an overlay into its initial position, preventing it from jumping. This PR is a resubmit of #5471.
…pplying to open connected overlay (#7805) Currently when updating the position of an open connected overlay (e.g. when the user is scrolling) we go through the same process for determining the preferred position as when the overlay was attached. This means that the preferred position could change, causing the overlay to jump. With these changes the consumer can decide to lock an overlay into its initial position, preventing it from jumping. This PR is a resubmit of #5471.
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Uses the element's last calculated position to re-align it, instead of recomputing the position completely. This prevents the overlay from jumping into the viewport when the user scrolls away.