User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.75 Safari/537.1 Steps to reproduce: Create a contentEditable area with at least one image. Register an event handler for the "dragstart" event to change something about the target image when it begins to be dragged, such as border color, CSS class, or other. Load the document in the browser and drag and drop the image to a new location. Actual results: The image gets copied to the new location but loses any changes made during dragging. Expected results: The image itself (not a copy) gets moved to the new location OR An exact copy of the image as of the dragend event gets placed at the new location

Working test case can be found here: http://jsbin.com/ohuzaj/3 Tested using browserstack.com, version 12 doesn't have this issue, but 13 and 14 do. As suggested by :ehsan this may be a regression from Bug 499008

Didn't notice the automatically generated User Agent, which is obviously not the relevant one. The relevant User Agent is this: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1 Sorry about too many comments.

Thanks for filing this, Mike! Neil, can you please take a look?

Yes, post bug 499008, any default data that would be added for dragging is now added to the data transfer before the dragstart event fires, rather than after in editable contexts. This is way the spec is, although it doesn't specify exactly how this should be handled for images, apart from setting the data transfer url type. (We serialize the html into source and store it in the data transfer)

I see. So does that mean that this bug is INVALID then?

Thanks Neil, for the quick response. That makes a lot of sense now. Can you please point me to the spec you're referring to?

The spec is at http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dnd As I said, it only mentions a few specific cases of how the data gets stored for dragging, and doesn't only mentions serializing the image as a url, so serializing the border colour isn't expected. That said, the spec is quite random is what it chooses to define and it often changes, so this bug is probably invalid. You could override the default data by setting the text/html and other types yourself during the dragstart event. If that's ok, we could close the bug. If not, you can contact me and I can suggest alternatives based on what you're actually trying to do.

Yes, overriding the default data absolutely works for me, as I am merely trying to find where the image ends up after being dropped. We can certainly close this bug since it sounds like it's invalid, and I'll shoot you an email about what I'm trying to do.

Thanks Neil!