615773 - Enable hiding/showing of drag image during drag

Status: RESOLVED INVALID

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Frank Yan (:fryn)]

We would like to be able to hide and show the drag image during a drag-and-drop event after dragstart.

We need this to implement tab detach animations (to hide the drag image until the tab has been dragged beyond the threshold for detachment), since we use the HTML5 drag-and-drop API internally. This is only requesting this ability for chrome code. There need not be any change to the API for content.

Comment 1

[Markus Stange [:mstange]]

I've looked into the possibility of this on Mac before and haven't found a way to do it. All the apps that change drag images during drag aren't using native drag images, they're using custom transparent windows and move them with the mouse pointer. We'd have to do something similar.

I'm wondering whether we should jump through the hoops of doing that emulation in the widget layer, or whether it'd be easier to just use a real window, or a panel, in the JavaScript code that implements tab dragging. What I have in mind is this:
 1. Use an empty image for the regular drag image.
 2. Place a floating panel that contains the dynamic drag image under the
    mouse pointer.
 3. Since this panel will probably swallow drag events, change all drag target
    calculations to use the mouse position on the screen instead of regular
    drag events.

Using a real XUL object as the drag image would also allow us to use CSS transforms and transitions on the drag image, for example for tweening a rectangular tab into a window preview during detaching.

Point 3 is nasty, though. If that's too much of a hassle, maybe we can add an API to panels that marks it as transparent to mouse events.

Comment 2

[Frank Yan (:fryn)]

(In reply to comment #1)

The panel exactly what I had in mind for a workaround. I just hoped that there would be an easier way. Sigh. :\

Comment 3

[Neil Deakin]

Using a panel is bug 533460. A proof of concept I had done somewhat worked but work on event handling was necessary.

Comment 4

[Frank Yan (:fryn)]

Marking this invalid, since it seems like panels is a better option, given the API, etc.

Feel free to reopen in the future _if_ there is clear evidence on the contrary.