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.

Sign up for GitHub

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

Jump to bottom

Wrong component fires drop event in Angular Material 7 #14231

Closed
iSerganov opened this issue Nov 21, 2018 · 4 comments · Fixed by #14257
Closed

Wrong component fires drop event in Angular Material 7 #14231

iSerganov opened this issue Nov 21, 2018 · 4 comments · Fixed by #14257
Assignees
@crisbeto
Labels
P2 The issue is important to a large percentage of users, with a workaround

Comments

@iSerganov
Copy link

iSerganov commented Nov 21, 2018 •
edited
Loading

Bug, feature request, or proposal:

Bug report.

What is the expected behavior?

Drop event is not fired on dropping the dragged item to the visible element over the hidden part of droppable list with elements built by ngFor.

What is the current behavior?

I have two components with dropabble lists aligned vertically one below the other. The top list contains a certain amount of elements with total height more than the height of the container. Overflow is set to auto so I have a vertical scrollbar as a result.
Once I drag and drop item from a third list to the BELOW component, the drop event is fired be the ABOVE one. During the debug I found out that the source element of the fired event is the item list which is not displayed, but located in the exact place of drop. So I expect that drop event is fired by the visible (BOTTOM) component, but not the one which is located on the "bottom layer".

What are the steps to reproduce?

  1. Build 2 components with a droppable lists and align them vertically (one above the other).
  2. Populate with ngFor directive the TOP list with some items in order to have list with height twice larger then the actual height of the component(set overflow-y to auto in order to have vertical scroll bar).
  3. Build any component with ability to drag and drop items from it to the created above components.
  4. Drag and drop item to the bottom component.

You will see that the actual drop event is not fired be the BOTTOM component towards which you have actually dropped the item, however the event is fired by the component above.

Please note that the position of both components is absolute.

What is the use-case or motivation for changing an existing behavior?

From my perspective, this is a critical bug which prevents me from using the latest version of angular material library in production.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

 "@angular/cdk": "7.0.4",
"@angular/common": "7.1.0-rc.0",
"@angular/compiler": "7.1.0-rc.0",
"@angular/core": "7.1.0-rc.0",
"@angular/forms": "7.1.0-rc.0",
"@angular/http": "7.1.0-rc.0",
"@angular/material": "7.0.4",

"@angular/cli": "7.1.0-rc.0",
"@angular/compiler-cli": "7.1.0-rc.0",
"typescript": "3.1.3"
@crisbeto
Copy link
Member

Can you provide a Stackblitz that illustrates the issue? You can use some of the examples on the docs as a base.

@iSerganov
Copy link
Author

Can you provide a Stackblitz that illustrates the issue? You can use some of the examples on the docs as a base.

https://stackblitz.com/edit/angular-uk3rnj?file=app%2Flist-overview-example.html

Please move the scroll of the top list to the top of it and drag items from the right list to the left bottom component several(4-5) times. You'll see that at least several times drop event of the top component is fired instead of the bottom one towards which you drops the item.

@crisbeto crisbeto self-assigned this Nov 22, 2018
@crisbeto crisbeto added needs investigation A member of the team needs to do further investigation to determine the root cause P2 The issue is important to a large percentage of users, with a workaround has pr and removed needs investigation A member of the team needs to do further investigation to determine the root cause labels Nov 22, 2018
crisbeto added a commit to crisbeto/material2 that referenced this issue Nov 24, 2018
@crisbeto
fix(drag-drop): account for out of view container and stacking order
77d4aed 
Currently we use the `ClientRect` of each drop container to determine whether an item can be dropped into it. Since the `ClientRect` doesn't know whether the container is scrolled out of the view or is positioned under another element, users can end up accidentally moving items into containers that aren't visible.

These changes rework the logic to look for which containers intersect with the user's pointer, and to filter based on whether the container is the top-most element at the pointer's position.

Fixes angular#14231.
@crisbeto crisbeto mentioned this issue Nov 24, 2018
Merged
crisbeto added a commit to crisbeto/material2 that referenced this issue Nov 24, 2018
@crisbeto
fix(drag-drop): account for out of view container and stacking order
ffa43db 
Currently we use the `ClientRect` of each drop container to determine whether an item can be dropped into it. Since the `ClientRect` doesn't know whether the container is scrolled out of the view or is positioned under another element, users can end up accidentally moving items into containers that aren't visible.

These changes rework the logic to look for which containers intersect with the user's pointer, and to filter based on whether the container is the top-most element at the pointer's position.

Fixes angular#14231.
crisbeto added a commit to crisbeto/material2 that referenced this issue Nov 24, 2018
@crisbeto
fix(drag-drop): account for out of view container and stacking order
948b483 
Currently we use the `ClientRect` of each drop container to determine whether an item can be dropped into it. Since the `ClientRect` doesn't know whether the container is scrolled out of the view or is positioned under another element, users can end up accidentally moving items into containers that aren't visible.

These changes rework the logic to look for which containers intersect with the user's pointer, and to filter based on whether the container is the top-most element at the pointer's position.

Fixes angular#14231.
crisbeto added a commit to crisbeto/material2 that referenced this issue Nov 27, 2018
@crisbeto
fix(drag-drop): account for out of view container and stacking order
dcf2ed9 
Currently we use the `ClientRect` of each drop container to determine whether an item can be dropped into it. Since the `ClientRect` doesn't know whether the container is scrolled out of the view or is positioned under another element, users can end up accidentally moving items into containers that aren't visible.

These changes rework the logic to look for which containers intersect with the user's pointer, and to filter based on whether the container is the top-most element at the pointer's position.

Fixes angular#14231.
crisbeto added a commit to crisbeto/material2 that referenced this issue Nov 30, 2018
@crisbeto
fix(drag-drop): account for out of view container and stacking order
89d54b3 
Currently we use the `ClientRect` of each drop container to determine whether an item can be dropped into it. Since the `ClientRect` doesn't know whether the container is scrolled out of the view or is positioned under another element, users can end up accidentally moving items into containers that aren't visible.

These changes rework the logic to look for which containers intersect with the user's pointer, and to filter based on whether the container is the top-most element at the pointer's position.

Fixes angular#14231.
crisbeto added a commit to crisbeto/material2 that referenced this issue Nov 30, 2018
@crisbeto
fix(drag-drop): account for out of view container and stacking order
28041eb 
Currently we use the `ClientRect` of each drop container to determine whether an item can be dropped into it. Since the `ClientRect` doesn't know whether the container is scrolled out of the view or is positioned under another element, users can end up accidentally moving items into containers that aren't visible.

These changes rework the logic to look for which containers intersect with the user's pointer, and to filter based on whether the container is the top-most element at the pointer's position.

Fixes angular#14231.
crisbeto added a commit to crisbeto/material2 that referenced this issue Dec 4, 2018
@crisbeto
fix(drag-drop): account for out of view container and stacking order
c05f16c 
Currently we use the `ClientRect` of each drop container to determine whether an item can be dropped into it. Since the `ClientRect` doesn't know whether the container is scrolled out of the view or is positioned under another element, users can end up accidentally moving items into containers that aren't visible.

These changes rework the logic to look for which containers intersect with the user's pointer, and to filter based on whether the container is the top-most element at the pointer's position.

Fixes angular#14231.
crisbeto added a commit to crisbeto/material2 that referenced this issue Dec 4, 2018
@crisbeto
fix(drag-drop): account for out of view container and stacking order
fd9a09c 
Currently we use the `ClientRect` of each drop container to determine whether an item can be dropped into it. Since the `ClientRect` doesn't know whether the container is scrolled out of the view or is positioned under another element, users can end up accidentally moving items into containers that aren't visible.

These changes rework the logic to look for which containers intersect with the user's pointer, and to filter based on whether the container is the top-most element at the pointer's position.

Fixes angular#14231.
mmalerba pushed a commit that referenced this issue Dec 4, 2018
@crisbeto @mmalerba
fix(drag-drop): account for out of view container and stacking order (#…
c5be8d3 
…14257)

Currently we use the `ClientRect` of each drop container to determine whether an item can be dropped into it. Since the `ClientRect` doesn't know whether the container is scrolled out of the view or is positioned under another element, users can end up accidentally moving items into containers that aren't visible.

These changes rework the logic to look for which containers intersect with the user's pointer, and to filter based on whether the container is the top-most element at the pointer's position.

Fixes #14231.
@crisbeto
Copy link
Member

crisbeto commented Dec 9, 2018

The fix should be in 7.1.2.

josephperrott pushed a commit to josephperrott/components that referenced this issue Jan 14, 2019
@crisbeto @josephperrott
fix(drag-drop): account for out of view container and stacking order (a…
9da940e 
…ngular#14257)

Currently we use the `ClientRect` of each drop container to determine whether an item can be dropped into it. Since the `ClientRect` doesn't know whether the container is scrolled out of the view or is positioned under another element, users can end up accidentally moving items into containers that aren't visible.

These changes rework the logic to look for which containers intersect with the user's pointer, and to filter based on whether the container is the top-most element at the pointer's position.

Fixes angular#14231.
@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 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@crisbeto crisbeto

Labels
P2 The issue is important to a large percentage of users, with a workaround
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(drag-drop): account for out of view container and stacking order crisbeto/material2
2 participants
@crisbeto @iSerganov