Issue metadata
Sign in to add a comment
|
Can't prevent dropped file from opening in Window when using custom drop event listener
Reported by
mingli...@salesforce.com,
Nov 16
|
||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36
Example URL:
Steps to reproduce the problem:
1. make one area in the page listen on drop event via using angular 6. (@HostListener('drop', ['$event']))
2. trying to drop a file into that area.
3. the file loaded in the browser instead of being handled by a custom event handler.
What is the expected behavior?
It should be handled by custom event handler first, otherwise, it's not possible to handle file drop on our own for our web application. It was working for the previous version (Version 70.0.3538.77 (Official Build) (64-bit)).
What went wrong?
Even if I have a custom handler for "drop" event, it seems that the browser's default handler (loading file in the window) has the highest priority and will never call through our event handler. In the previous version 70.0.3538.77, it's calling our event handler first then we can easily preventDefault and stopPropagation.
Does it occur on multiple sites: Yes
Is it a problem with a plugin? No
Did this work before? Yes 70.0.3538.77
Does this work in other browsers? Yes
Chrome version: 70.0.3538.102 Channel: stable
OS Version: OS X 10.13.6
Flash Version:
Please let me know if there's any workaround or that is a bug will be fixed soon. Thank you!
,
Nov 18
,
Nov 21
we are seeing that our drag drop listeners are not getting fired if the dragging happens within a modal dialog that presents itself on top of an iframe(the url of the iframe has a different domain). Note, iframe happens to also allow cross domains. Is this an intended security feature or a bug in the latest version? Thank you!
,
Nov 21
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 22
@jstenback: As per comment#3, could you please provide an update that whether it is an intended security feature or a bug. Thanks.!
,
Nov 22
,
Nov 22
Can you provide us with an example?
,
Nov 30
The NextAction date has arrived: 2018-11-30
,
Dec 5
We have also seen this issue in a similar scenario where a file management tool is positioned over an iframe (in our case a preview of a webpage that can be edited directly). After a recent release of Chrome, users are no longer able to reliably upload files when dragging them into the tool because a portion of the drop zone is over an iframe that has a different origin. I put together a simple test case that demonstrates the issue. https://www.gregorycornelius.com/tests/chrome-dnd-bug.html Is this the behavior that we should expect moving forward?
,
Dec 17
,
Jan 4
One interesting note after playing with gcornelius's test case is that applying `visibility: hidden` to the iframe does cause D&D events to work as expected again. While that is not a great workaround at all—since it totally hides the iframe—I thought it was notable because I assumed `display: none` would fix things but that `visibility: hidden` would not. Note, I also tried `opacity: 0.5` (and various `sandbox` iframe attributes) but those don't change anything. ps: This was my thinly veiled attempt to bump this issue (e.g. attempt to provide some small, but useful information while I'm really only trying to escalate the fix) ;-) |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by jstenback@chromium.org
, Nov 16Labels: Needs-Feedback
NextAction: 2018-11-30