STR:

1. Open multiple tabs in a window. Actually, you don't even need multiple ones.
2. Drag a tab out of the window to an empty spot on your display.

The thumbnail of the page floats back to the original location of the tab, communicating that the drag was unsuccessful. However, it was successful: the tab moves to its own window. We should fire the animation only if something goes wrong. Not only is this confusing and misleading, but it delays the opening of the new window for a second while the animation plays.

This has been broken for years and years, so start wide if you try to bisect it. Oddly, I don't see an existing bug about it.

Neil, do you happen to remember if we can control this with DOM drag & drop APIs? I would expect we can, but then, like Erik, I'm surprised that we're not already doing that...

I can reproduce this on Linux as well.

Glad/sad it's not just me and my wacky config! :-)

I vaguely remember that we had an old bug filed on this but can't find it either.

It is easy to do when dropping on the same application just by setting the dropEffect correctly. This appears to happen when dragging tabs around for example. However, this won't work when dropping on another application/the desktop/etc as the destination is expected to set and determine this.

However, we could add something possibly platform specific that might work in this case.

On Mac, we would need to set the animatesToStartingPositionsOnCancelOrFail flag at https://searchfox.org/mozilla-central/rev/7908ce29657cfd623993046bd8e38664e1c0b28e/widget/cocoa/nsDragService.mm#319
I'm not sure if it can be set dynamically though.

On GTK, we can just return false from the drag-failed handler at https://searchfox.org/mozilla-central/rev/7908ce29657cfd623993046bd8e38664e1c0b28e/widget/gtk/nsDragService.cpp#1705 to prevent the animation.

(In reply to Neil Deakin from comment #5)

It is easy to do when dropping on the same application just by setting the dropEffect correctly. This appears to happen when dragging tabs around for example. However, this won't work when dropping on another application/the desktop/etc as the destination is expected to set and determine this.

However, we could add something possibly platform specific that might work in this case.

On Mac, we would need to set the animatesToStartingPositionsOnCancelOrFail flag at https://searchfox.org/mozilla-central/rev/7908ce29657cfd623993046bd8e38664e1c0b28e/widget/cocoa/nsDragService.mm#319
I'm not sure if it can be set dynamically though.

Happily, this seems to work, and anyway I think just assuming we don't need this animation for any tab drags is better than the status quo.

On GTK, we can just return false from the drag-failed handler at https://searchfox.org/mozilla-central/rev/7908ce29657cfd623993046bd8e38664e1c0b28e/widget/gtk/nsDragService.cpp#1705 to prevent the animation.

In name this seemed the easier of the two fixes, but I can't get it to work. I've attached the WIP patch. The logging prints the right things, but on my ubuntu linux vm, I still see drag animations. I'm completely unfamiliar with GTK and how I could possibly work out why doing what it documents is the Right Thing doesn't actually work, so I will probably move fixing linux to a follow-up bug.

https://hg.mozilla.org/mozilla-central/rev/b2954fa754d2

Comment on attachment 9312519 [details]
WIP: Bug 1635761 - non-working attempt to get Linux to also not show drag cancel animation for tabs dragged out of the window.

Revision D166967 was moved to bug 1811241. Setting attachment 9312519 [details] to obsolete.