dragging a tab to a new window should focus that window before drop, in order to allow inserting the tab in the desired place.

It's very difficult to drag and drop a tab from one window onto another, because when you do that, you have to look for the tiny bit of chrome in the other window and drop the tab there. Then you have to switch to that window and re-arrange the way you intended to.

You can drag over the task bar to raise a different window. This is standard behavior among various window managers.

While true Dao, it's an inferior UE. This bug should be fixed, but it's not a regression nor is it a blocker.

Comment on attachment 539673 [details] [diff] [review] Patch v1 This needs tests. Also, focusing should happen only when handling trusted events. And, which dom window do we want to focus? The content window or the chrome window? I would guess the content window. The patch would end up calling focus on the content window and when on the chrome window, I think.

So, would it work if you'd test that if aVisitor.mEvent->mOriginalTarget is nsIContent, and it's GetOwnerDoc == mDoc

I don't think this should be used for every drag. It should only be applicable to tab dragging. Thus, it should be handled in tabbrowser.xml or somewhere close by.

As per Neil's comment, I've moved the focus-changing code to the browser.xml level and made it apply only to tabs. Working on writing tests for it now.

Last patch killed a newline.

Patch has been updated and tests have been added.

Comment on attachment 542966 [details] [diff] [review] Patch v3 This patch seems to conflict with bug 455694...

(In reply to comment #11) > Comment on attachment 542966 [details] [diff] [review] [review] > Patch v3 > > This patch seems to conflict with bug 455694... Yes. Could we wait for bug 455694 before spending more time on this? In its latest revision, the patch for bug 455694 eschews the drag and drop API for tab dragging altogether due to performance issues.

The patch for bug 455694 now fixes this too.

Fixed by patch in bug 455694.

verified on Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0

this is broken in 12.0b1, probably due to 455694 backout

In Firefox 23, an accepting dragging tab window is not get focused even after drop. Moreover, any drop (links, files, text etc) do not cause window activation (at least on Windows7) (https://bugzilla.mozilla.org/show_bug.cgi?id=332346)

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)