Drag 'ghost' generated from drag source AFTER the dragstart event fires (should be generated before)
Reported by
m...@netrivet.com,
Apr 28 2016
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36 (prophototech)pp_dev Example URL: http://codepen.io/mattdietsche/pen/qZJPRz Steps to reproduce: 1. Drag the red element around. What is the expected behavior? Drag ghost appears, source element hidden What went wrong? Drag ghost does not appear, source element hidden. To create repro: 1. Create a draggable element 2. Add a dragstart listener that sets the opacity of the target element to 0 3. Drag the element Workaround: Adding a 1ms timeout to opacity change in the dragstart listener. Not sure if there was an order of operations change or what... Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes 49? I think. Just noticing it now and am on 50 Does this work in other browsers? Yes Chrome version: 49.0.2623.110 Channel: stable OS Version: OS X 10.10.5 Flash Version: Shockwave Flash 21.0 r0
,
Apr 29 2016
,
Sep 5 2016
According to my reading of the spec [1], this bug has merit -- the drag and drop feedback ("ghost") should the DOM element's rendering when the dragging starts. Specifically, according to the processing model [2], the drag data store's default feedback [3] should be computed (at step 8) before firing the dragstart event (at step 9). As long as the dragstart handler doesn't call setDragImage [4] (which it can do, because the drag data store is in readwrite mode during dragstart [5]), the feedback must be initialized using the default feedback (at step 10 in [2]).
That being said, our behavior does seem to match Safari's (observed on the given URL after downgrading fat arrows to the old-school function syntax). So we'll have to think about what we want to do here.
[1] https://html.spec.whatwg.org/multipage/interaction.html#dnd
[2] https://html.spec.whatwg.org/multipage/interaction.html#drag-and-drop-processing-model
[3] https://html.spec.whatwg.org/multipage/interaction.html#drag-data-store-default-feedback
[4] https://html.spec.whatwg.org/multipage/interaction.html#dom-datatransfer-setdragimage
[5] https://html.spec.whatwg.org/multipage/interaction.html#event-dnd-dragstart
,
Nov 1 2016
,
Nov 2 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 6 2017
*snooze*
,
Nov 7
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 8
,
Nov 8
,
Nov 8
,
Nov 8
Echoing #3, it seems we're generating the ghost as based off of the drag source, which is fine. However, the ghost should be computed based off of the drag source's state before the drag start handler is fired, whereas it's currently computed based off the drag source's state (0% opacity) after the drag start handler is fired. Repro'ed on Mac/Chrome 70.0.3538.77, Mac/Firefox 63.0.1, and Mac/Safari 12.0.1. As we're consistent with all tested browsers, I believe that priority to fix this is very low. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by m...@netrivet.com
, Apr 28 2016