781611 - Image dragged/dropped inside contentEditable loses changes made after ondragstart

Status: RESOLVED INVALID

(Core :: DOM: Editor, defect)

Description

[Mike Ivanov]

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

Comment 1

[Mike Ivanov]

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

Comment 2

[Mike Ivanov]

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.

Comment 3

[(no longer active)]

Thanks for filing this, Mike!

Neil, can you please take a look?

Comment 4

[Neil Deakin]

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)

Comment 5

[(no longer active)]

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

Comment 6

[Mike Ivanov]

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?

Comment 7

[Neil Deakin]

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.

Comment 8

[Mike Ivanov]

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.

Comment 9

[(no longer active)]

Thanks Neil!