Moving a tab to a new position in the tab bar by dragging and dropping sometimes fails, causing it to return back to its original position when dropped. This happens even when the drag ends cleanly over a different tab position and the other tabs have moved to accommodate it. See the attached short video. This happens on Ubuntu 16.04 with e10s windows only and not on Windows 10.

Likely a duplicate of 1266435.

(In reply to Neil Deakin from comment #1) > Likely a duplicate of 1266435. I've been noticing this bug for as long as I can remember e10s being available with Aurora, well before the regression that caused Bug 1266435.

> > Likely a duplicate of 1266435. > > I've been noticing this bug for as long as I can remember e10s being > available with Aurora, well before the regression that caused Bug 1266435. Kestrel, this does sound exactly like 1266435, but you can confirm if they're unrelated by testing this on Aurora, as the regression that caused 1266435 is ostensibly gone on that channel. (And it would be useful for us to know, because that could mean that 1266435 is not actually causally related to 1256952.)

Bug 1266435 only happens when dragging a tab out of the tab bar and then returning, the tab stops moving and cannot be rearranged. This bug does not require dragging out of the tab bar and the dragged tab always moves but sometimes resets back to where it was when dropped. It seems to happen more often when the drag is started quickly, that is, when there is a short time between mousedown and the drag threshold being exceeded. It affects latest Aurora with a clean profile as seen in the attached video.

(In reply to Kestrel from comment #4) > It seems to happen more often when the drag is started quickly, that is, > when there is a short time between mousedown and the drag threshold being > exceeded. This is incorrect, it happens even when waiting one second between mousedown and exceeding drag threshold. The speed of the drag seems to be related as it never happens with very slow dragging.

kestrel, can you still reproduce this?

I can still reproduce this on both Nightly 49.0a1 (2016-05-05) and Aurora 48.0a2 (2016-05-05).

Neil, this should be fixed right?

It should be fixed, but I am unable to reproduce this. Debugging would require investigating the "drop" handler in tabbrowser.xml

No drop event is being dispatched, instead getting dragend event which shouldn't happen as per the comment "this event isn't dispatched when the tab is moved within the tabstrip". Turns out to be a GTK issue completely unrelated to e10s that goes way back to Firefox 26 and earlier, e10s may have made it more noticeable since it is related to event timing.

dragend should always fire. Can you produce a log with NSPR_LOG_MODULES=nsDragService:5 set? If it happens in non-e10s this would be a bit better as it would be easier to follow the log.

Drop works: > 298104640[7f791079d5c0]: nsDragService::StartDragSession > 298104640[7f791079d5c0]: nsDragService::SetCanDrop 1 > 298104640[7f791079d5c0]: nsDragService::ReplyToDragMotion 1 > 298104640[7f791079d5c0]: nsDragService: dispatch drag leave (7f78ec8c9000) > 298104640[7f791079d5c0]: nsDragService::StartDragSession > 298104640[7f791079d5c0]: nsDragService::SetCanDrop 1 > 298104640[7f791079d5c0]: nsDragService::ReplyToDragMotion 1 > 298104640[7f791079d5c0]: nsDragService::StartDragSession > 298104640[7f791079d5c0]: nsDragService::EndDragSession 1 > 298104640[7f791079d5c0]: invisibleSourceDragEnd Drop fails: > 298104640[7f791079d5c0]: nsDragService::StartDragSession > 298104640[7f791079d5c0]: nsDragService::SetCanDrop 1 > 298104640[7f791079d5c0]: nsDragService::ReplyToDragMotion 1 > 298104640[7f791079d5c0]: nsDragService: dispatch drag leave (7f78ec8c9000) > 298104640[7f791079d5c0]: invisibleSourceDragEnd > 298104640[7f791079d5c0]: nsDragService::EndDragSession 1 It always fails when "dispatch drag leave" happens just before ending the drag, eDragTaskDrop does not occur which can be seen by invisibleSourceDragEnd occurring before EndDragSession. If the cursor is moved after "dispatch drag leave" triggering eDragTaskMotion then the drop will work, so there is a small window between eDragTaskLeave and eDragTaskMotion where the drop will fail unexpectedly.

OK, since I'm not able to reproduce this, are you ok trying to debug this yourself with help? If so, let's look at the dragover handler. Look for <handler event="dragover"> in tabbrowser.xml The only possibility that I can think of is that it is returning early in the first few lines due to the return value of _getDropEffectForTabDrag Some useful values to look at: - the return value of _getDropEffectForTabDrag - event.dataTransfer.dropEffect - event.dataTransfer.effectAllowed - dt.types[0]

This is not limited to tabbrowser.xml, all dragging and dropping is affected including links, text and customizable buttons (explains a lot of weirdness in retrospect). When dragging a bookmark item over a bookmarks folder, normally the folder becomes highlighted and after a short delay automatically opens, but when dragging stops at "nsDragService: dispatch drag leave" the folder is not highlighted and does not open.

When there is no GTK drag-motion signal after drag-leave, then no GTK drag-drop signal is received. This makes sense according to the GTK docs, the drag-motion signal is used to determine if drop is possible so if there is no drag-motion after drag-leave then the cursor is in limbo and it shouldn't be possible to drop. I tested some other GTK apps and it occurs there also, even with the Unity Launcher. When repositioning an item in the Unity Launcher, sometimes the other items don't move to accommodate unless there is an additional drag-motion (suggesting the last signal was drag-leave), this is different to Firefox where the tabs always make room even if the drop is destined to fail. I could also get it to occur in gedit when dragging highlighted text but not with dragging tabs. In general it seems more noticeable in Firefox. So this is most definitely an upstream GTK bug, possibly exacerbated by some implementation specifics in Firefox.

Filed upstream GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=766429

closing out since this is a gtk bug per comment 15.