Skip to content

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

Closed

Conversation

crisbeto
Copy link
Member

@crisbeto crisbeto commented Jul 2, 2017

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.

…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.
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Jul 2, 2017
Copy link
Member

@jelbourn jelbourn left a 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?

@crisbeto
Copy link
Member Author

crisbeto commented Jul 5, 2017

Initially I did it with overlayRef.getState().positionStrategy, but that looked weird, because it assumes that the scroll strategy will only be used on a connected overlay (which will be the case most of the time, but we don't enforce it). Similarly, we have the dispose method which is only relevant for the global strategy, but it has to be implemented everywhere.

crisbeto added a commit to crisbeto/material2 that referenced this pull request Oct 15, 2017
… 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.
@crisbeto
Copy link
Member Author

Closing in favor of #7805.

@crisbeto crisbeto closed this Oct 15, 2017
crisbeto added a commit to crisbeto/material2 that referenced this pull request Oct 29, 2017
…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.
jelbourn pushed a commit that referenced this pull request Nov 19, 2017
…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.
jelbourn pushed a commit that referenced this pull request Nov 20, 2017
…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.
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla: yes PR author has agreed to Google's Contributor License Agreement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants