Skip to content
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

Inconsistencies with cdkDropListAutoScroll #16647

Closed
Ploppy3 opened this issue Jul 31, 2019 · 7 comments · Fixed by #16675
Closed

Inconsistencies with cdkDropListAutoScroll #16647

Ploppy3 opened this issue Jul 31, 2019 · 7 comments · Fixed by #16675
Assignees
Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent

Comments

@Ploppy3
Copy link

Ploppy3 commented Jul 31, 2019

Reproduction

On this repro you can see that's it's near impossible to drag the last element to the top.
I was not able to reproduce my problem though, which is the opposite, I can drag from the bottom to the top but can't drag from top to bottom at all.

Hardly working towards the top (removing border-bottom on element seems to fix the problem)
https://stackblitz.com/edit/angular-ambqxc?file=app/cdk-drag-drop-sorting-example.css

Not working at all towards top
https://stackblitz.com/edit/angular-ambqxc-xlst4y?file=app/cdk-drag-drop-sorting-example.css

Not working at all towards top, hardly working towards bottom
(withing an absolutely positioned body)
https://stackblitz.com/edit/angular-ambqxc-ehsbz5?file=styles.css

Hardly working in both directions
(withing an absolutely positioned body ; filling height of a flex container)
https://stackblitz.com/edit/angular-ambqxc-bmdjkk?file=styles.css

Expected Behavior

Auto-scroll should work consistently in every directions.

Actual Behavior

Auto-scroll works sometimes only.

Environment

  • Angular: 8.2.0-rc.0
  • CDK/Material: 8.1.2
  • Browser(s): Chrome
  • Operating System: Windows
@crisbeto
Copy link
Member

I wasn't really able to reproduce it in the demos, but what I think might be going on is that the scrolling regions overlap. The way it's set up at the moment is that it looks for whether your pointer is in the top X% of either the list or the window. If those two regions overlap it just takes one. By saying "not being able to drag", do you mean that the view isn't scrolling or the element isn't being dragged at all?

@Ploppy3
Copy link
Author

Ploppy3 commented Jul 31, 2019

I mean that the view is not scrolling when dragging an element to the top/bottom of a vertical list, sorry for not being clear enough.

@crisbeto
Copy link
Member

That sounds like the scroll regions are overlapping. You should be able to verify if that's the case by pushing the drop list somewhere further down the page (e.g. in the middle) and seeing if the auto scroll starts working.

@Ploppy3
Copy link
Author

Ploppy3 commented Jul 31, 2019

After a small test, I think it is what you are pointing out, let me explain:
In order to have the most freedom with router animations, my components are in position: fixed and fill the height and width of the <mat-drawer-content> component.
In the following picture, you have:

image

  • Left: nav-list
  • Top right: toolbar
  • Bottom-right: d&d list

The d&d list fills the height available from the and therefore is also constantly at the bottom of the window. The auto-scroll only work at the top of the list.

What I tested which seems to confirm your point: if I remove the toolbar, the list is now at the top of the window and auto-scroll stopped working.

@andrewseguin
Copy link
Contributor

@crisbeto is this an issue we need to resolve, or is it just an issue with having overlapping regions

@andrewseguin andrewseguin added the P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent label Jul 31, 2019
@crisbeto
Copy link
Member

crisbeto commented Aug 1, 2019

It's definitely a valid issue that should be resolved.

@crisbeto crisbeto self-assigned this Aug 3, 2019
@crisbeto crisbeto added the has pr label Aug 3, 2019
crisbeto added a commit to crisbeto/material2 that referenced this issue Aug 3, 2019
The way auto-scrolling is currently set up is that we have regions that are X% of the width/height of a node and whenever the user's pointer gets into the region, we start scrolling either the element or the page. The problem with our current approach is that as soon we find that the user's pointer is in one node's scroll region, we disregard any of the other scroll regions and we start scrolling, even if the element can't actually scroll. This is problematic in cases where the scroll list might be close to the viewport's edge and thus it could have its region overlapping with the viewport's. These changes address the issue in two ways:

1. We have the list's scroll regions take precedence over the ones of the page.
2. If the regions overlap, we check whether the element can continue scrolling that direction and if it can't, we start scrolling the page.

Fixes angular#16647.
crisbeto added a commit to crisbeto/material2 that referenced this issue Aug 3, 2019
The way auto-scrolling is currently set up is that we have regions that are X% of the width/height of a node and whenever the user's pointer gets into the region, we start scrolling either the element or the page. The problem with our current approach is that as soon we find that the user's pointer is in one node's scroll region, we disregard any of the other scroll regions and we start scrolling, even if the element can't actually scroll. This is problematic in cases where the scroll list might be close to the viewport's edge and thus it could have its region overlapping with the viewport's. These changes address the issue in two ways:

1. We have the list's scroll regions take precedence over the ones of the page.
2. If the regions overlap, we check whether the element can continue scrolling that direction and if it can't, we start scrolling the page.

Fixes angular#16647.
jelbourn pushed a commit that referenced this issue Aug 27, 2019
…ing (#16675)

The way auto-scrolling is currently set up is that we have regions that are X% of the width/height of a node and whenever the user's pointer gets into the region, we start scrolling either the element or the page. The problem with our current approach is that as soon we find that the user's pointer is in one node's scroll region, we disregard any of the other scroll regions and we start scrolling, even if the element can't actually scroll. This is problematic in cases where the scroll list might be close to the viewport's edge and thus it could have its region overlapping with the viewport's. These changes address the issue in two ways:

1. We have the list's scroll regions take precedence over the ones of the page.
2. If the regions overlap, we check whether the element can continue scrolling that direction and if it can't, we start scrolling the page.

Fixes #16647.
mmalerba pushed a commit to mmalerba/components that referenced this issue Aug 27, 2019
…ing (angular#16675)

The way auto-scrolling is currently set up is that we have regions that are X% of the width/height of a node and whenever the user's pointer gets into the region, we start scrolling either the element or the page. The problem with our current approach is that as soon we find that the user's pointer is in one node's scroll region, we disregard any of the other scroll regions and we start scrolling, even if the element can't actually scroll. This is problematic in cases where the scroll list might be close to the viewport's edge and thus it could have its region overlapping with the viewport's. These changes address the issue in two ways:

1. We have the list's scroll regions take precedence over the ones of the page.
2. If the regions overlap, we check whether the element can continue scrolling that direction and if it can't, we start scrolling the page.

Fixes angular#16647.
@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 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants