On Mac OS X, background windows are usually activated on mousedown. However, when dragging things out of a background window, it shouldn't be activated on the drag gesture's mousedown - instead, draggable things should delay the window's activation until mouseup (see NSView's shouldDelayWindowOrderingForEvent method). In Firefox 2 you could drag things out of background windows without focusing them when another Firefox window was activated (but not when another app was activated). In Firefox 3, all mousedowns immediately activate the background window and the mousedown event is ignored (bug 392188), so you always have to click twice to drag something out of a background window. (It's possible to work around this by holding the Cmd key.) I don't know how Firefox 2 did it (remember the mouse down event until it's clear that the user is initiating a drag session and only send it then?), but I think it's nice. What can be done here? We'll probably have to fix bug 392188 first and then mark mousedown events on draggable things as delaying window activation or something. I'm just filing this as a bug to get it out of my head.

I think the real problem is that while dragging Apple Key + tab (switching between programs) works but Apple Key + ~ (switching between windows of the program) doesn't. If you could switch between windows via keyboard shortcuts it would make this much less of a problem.

That's bug 427410, which most people don't see. Switching between windows with Cmd + ~ works fine for me.

I'm not so sure. CMD + ~ works fine for me when I'm not dragging tabs. It only fails when I'm dragging them.

Oops, sorry, I misunderstood you. You're right. But I'm not sure we should allow Cmd + ~ while dragging - no other application I tested does that. I just noticed that Exposé works while dragging, so you can use that as a (somewhat imperfect) workaround.

In bug 392188 comment 13, Neil Deakin says: > Note that Mozilla used to have the capability to drag from inactive windows > long (long long) ago, but the code isn't being used any more. The are remnants > of this in the windows widget code. > > What this does is fire a NS_MOUSE_ACTIVATE event and the responder sets the > acceptActivation field to false if it doesn't want the window to come to the > front. On Windows, a number of flags can be set which identify whether the > window should be activated and/or the mouse event fired or ignored, so this > managed to allow drags from background windows. > > I'm not sure how Mac specifies this, but we should either make use of this or a > similar technique such that UI elements can either set an attribute or respond > to an event to indicate what behaviour is desired. With Cocoa we can use NSView's "shouldDelayWindowOrderingForEvent" method and "send a preventWindowOrdering message to NSApp": http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html#//apple_ref/occ/instm/NSView/shouldDelayWindowOrderingForEvent:

(In reply to comment #0) > On Mac OS X, background windows are usually activated on mousedown. However, > when dragging things out of a background window, it shouldn't be activated on > the drag gesture's mousedown - instead, draggable things should delay the > window's activation until mouseup (see NSView's > shouldDelayWindowOrderingForEvent method). > ref bug 38646