User Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120429 Firefox/14.0a2
Build ID: 20120429042006
Steps to reproduce:
Drag tab from 'Tabbar' to any area attempting to 'open' tab in 'new window'
Actual results:
Desktop Locks. Cursor remains a 'fist' as if 'gripping' the tab, but tab 'returns' to tab bar and desktop is locked. I can not click on anything, activate my 'autohide' taskbar, click on 'new snapshot' of my screencapture app when i alt+tab it to for ground.
I have to ctrl+esc , tab, del (KILL) firefox and then cursor returns to normal and desktop functionality returns (openSuSE 12.1 with KDE 4.7.2 and kernel 3.1.10-1.9-desktop)
Expected results:
tab opens in 'new window'

On trunk:
I can reproduce this only with tabs.onTop.
Speed is not important.
What seems to be important is that the distance dragged across the browser chrome is small.
Pressing the mouse button near the bottom of the tab and dragging directly down is enough.
The drag (and its pointer grab - lock) does not begin until the pointer is moved back over the browser chrome.
The drag session receives drag-failed and drag-end immediately, but the pointer remains grabbed.
The keyboard is not grabbed. Using a keyboard to open another popup window will cause a new pointer grab and reset the cursor state.

The regression is due to the timestamp used to start the drag changing from the time of the last button press to the time of the mouse motion, after the button release, that started the drag.
The last button release time used in code added in bug 307184 to end the drag is older than the mouse motion timestamp, and so the pointer ungrab fails. GTK still thinks it has ended the drag and so things are in a bad state.
The code added in bug 307184 was intended to handle the situation where the button release event is in the event queue at the time the drag started. It still functions as intended in that situation.
The regression is that the code added in bug 307184 no longer happens to save us from bug 648477, which is when the drag begins after the button release has been processed.

The code from bug 307184 was to work around https://bugzilla.gnome.org/show_bug.cgi?id=347277 which was fixed for GTK+ 2.10.1.
We don't support systems older than 2.12, so we can assume we have the fix.
However, the mHiddenWidget that nsDragService uses as the drag source is not in the same window group as the window where the mouse button was pressed (which is the same window that receives the matching release).

I wondered whether we could remove our window group code, putting all windows in the default group. Window groups affect grabs so these are my notes on grabs.
There are two types of grabs that Gecko makes use of:
gdk_pointer_grab and gtk_grab_add.
gdk_pointer_grab behaves differently depending on the owner_events parameter.
If owner_events is false this redirects mouse events to the specified
(possibly child) GdkWindow only. This changes behavior only at the X server
and so doesn't affect events that have already been sent.
If owner_events is true mouse events from only outside the (toplevel) window
group are redirected to the specified GdkWindow. Events that would normally
be delivered to the window group continue to be delivered as normal. This
is implemented partially on the X server, but events sent to the same client
but different window group are redirected by GTK, so this part is effective
for events that have already been sent but are still in the queue.
gtk_grab_add means that any event that would be delivered to the same
(toplevel) window group is redirected to the specified widget. The window in
the event is not changed and so motion_notify_event_cb etc in nsWindow.cpp
redirects it back to the original window anyway.
gtk_grab_add is implemented in GTK and so affects events already queued.
gtk_grab_add also influences keyboard events. It doesn't change the focus
widget (nor toplevel window) but does redirect keyboard events to the
specified widget. key_press_event_cb etc in nsWindow.cpp redirects the
event back to the focus window.
For Gecko, apparently the only difference that our gtk_grab_add makes is
that it keeps events from being delivered to GtkWidgets of plugins.
gtk_dialog_run uses gtk_grab_add to make the window modal wrt those windows
in the same group.
If we were to remove the window group code:
1. Bug 741283 would extend to all windows, not just the one that opened the menu.
That would be a bit sad, but not major.
2. Modal windows would be app-modal instead of window-modal.
Currently Gecko modal windows are implemented using nested event loops so
they should be app-modal to function properly.
However, window-modal dialogs are much more pleasant than app modal dialogs.
Despite not always working properly, it would seem quite a regression to
switch to app modal dialogs.

What I suggest we do is put mHiddenWidget in the same window group as the window where the mouse button was pressed, so that the code added for bug 307184 can be removed. This will also help with bug 751429.
There is then no button release event that gets dispatched with the wrong timestamp.
This patch does not work around bug 648477, but leaves us in a much better (and un"lock"ed) state. nsDragService will still start a drag session when asked, but a click will end the drag. Bug 648477 means that the drag that the user intended to start, starts late.

Comment on attachment 620582[details][diff][review]
Put the hidden drag widget in the window group of the source node
I'll explain a couple of things:
>- mHiddenWidget = gtk_invisible_new();
>+ mHiddenWidget = gtk_window_new(GTK_WINDOW_POPUP);
GtkInvisibles don't have a window group. This GtkWindow is realized but never shown so it is still invisible.
>- if (gtk_grab_get_current() == data->mWidget) {
>+ if (gtk_widget_has_grab(data->mWidget)) {
This check isn't exactly the same, but close enough and easier than finding the current grab in the widget's window group.
_has_grab() doesn't on its own imply *the* active grab, but the gtk drag code will immediately start to end the drag if this widget is no longer *the* grab, at which point it will remove its grab.

We could think about applying this fix to mozilla14 aurora.
It feels too late to consider such a change for mozilla13 beta.
AFAICT the problem exists only we tabs.onTop is set to false or the navigation bar is hidden.
The workaround to escape without killing Firefox is to use the keyboard to open a menu. e.g Alt+F, but this is not obvious.

Tracking for 13 and 14 since it's a regression in 13 as well - can we get a risk assessment here? Why does comment 15 suggest it feels too late to fix this on beta? We've still got 3 more weeks of beta testing and if this got in today it could go in tomorrow's beta 3 build.

There is a moderate risk with this fix. Drags involve coordination across a number of actions and depend on GTK behaviour. If any part of the effort doesn't behave as expected, then things can fall over.
The other option to consider is backing out bug 500081, bug 725047, bug 724966, bug 724967, but there is also risk in doing that if something else is now depending on the bugs that were fixed.
I'd recommend applying the fix to alpha, but with this bug affecting only tabs.onTop or missing navigation bar, I don't know whether it's worth adding risk to beta/13.

Comment on attachment 620582[details][diff][review]
Put the hidden drag widget in the window group of the source node
[Triage Comment]
Given the risk assessment and non-default STR for Firefox, approving for Aurora 14 and declining for Beta 13. CC'ing Callek in case he wants to take this fix for SM though.

(In reply to Karl Tomlinson (:karlt) from comment #18)
> There is a moderate risk with this fix. Drags involve coordination across a
> number of actions and depend on GTK behaviour. If any part of the effort
> doesn't behave as expected, then things can fall over.
>
> The other option to consider is backing out bug 500081, bug 725047, bug
> 724966, bug 724967, but there is also risk in doing that if something else
> is now depending on the bugs that were fixed.
>
> I'd recommend applying the fix to alpha, but with this bug affecting only
> tabs.onTop or missing navigation bar, I don't know whether it's worth adding
> risk to beta/13.
Karl, just to let you know. I've Never run ff with 'tabs.ontop' and always have nav bar visible. My experience with this issue has always been with tabs on the bottom and 'location bar' visible.. Just letting you know so you make fully informed decisions.
Thanks for all you do.. I try and follow, but you guys (gals) lose me when your really get going.. : )
Landis.

Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0
Verified on Ubuntu 12.04 in F14 beta7.
Detaching tabs works as expected - both with tabs on top enabled and disabled. No hang/desktop lock.