597989 - dragging a tab to a new window should focus that window before drop

Status: REOPENED

(Firefox :: Tabbed Browser, enhancement)

Description

[eyal gruss]

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

Comment 1

[juan becerra [:juanb]]

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.

Comment 2

[Dão Gottwald [:dao]]

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

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

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 4

[Jez Ng [:int3]]

Attachment: Patch v1

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

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

Comment 7

[Neil Deakin]

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.

Comment 8

[Jez Ng [:int3]]

Attachment: Patch v2

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.

Comment 9

[Jez Ng [:int3]]

Attachment: Patch v2

Last patch killed a newline.

Comment 10

[Jez Ng [:int3]]

Attachment: Patch v3

Patch has been updated and tests have been added.

Comment 11

[Dão Gottwald [:dao]]

Comment on attachment 542966 [details] [diff] [review]
Patch v3

This patch seems to conflict with bug 455694...

Comment 12

[Frank Yan (:fryn)]

(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.

Comment 13

[Frank Yan (:fryn)]

The patch for bug 455694 now fixes this too.

Comment 14

[Frank Yan (:fryn)]

Fixed by patch in bug 455694.

Comment 15

[Florin Strugariu [:Bebe]]

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

Comment 16

[eyal gruss]

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

Comment 17

[danya.postfactum]

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)

Comment 18

[Jonathan Watt [:jwatt]]

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