Open Bug 597989 Opened 13 years ago Updated 6 months ago

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


(Firefox :: Tabbed Browser, enhancement)




Tracking Status
blocking2.0 --- -


(Reporter: eyalgruss, Unassigned)


(Depends on 1 open bug, Blocks 2 open bugs)


(4 keywords)


(1 file, 3 obsolete files)

dragging a tab to a new window should focus that window before drop, in order to allow inserting the tab in the desired place.
Blocks: cuts-focus
Whiteboard: parity-chrome
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.
blocking2.0: --- → ?
OS: Windows XP → All
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.
blocking2.0: ? → -
Attached patch Patch v1 (obsolete) — Splinter Review
Attachment #539673 - Flags: review?(Olli.Pettay)
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.
Attachment #539673 - Flags: review?(Olli.Pettay) → review-
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.
Attached patch Patch v2 (obsolete) — Splinter Review
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.
Attachment #539673 - Attachment is obsolete: true
Attached patch Patch v2 (obsolete) — Splinter Review
Last patch killed a newline.
Attachment #542368 - Attachment is obsolete: true
Depends on: 465186
Attached patch Patch v3Splinter Review
Patch has been updated and tests have been added.
Attachment #542369 - Attachment is obsolete: true
Attachment #542966 - Flags: review?(dao)
No longer depends on: 465186
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.
Depends on: 455694
Fixed by patch in bug 455694.
Assignee: nobody → fryn
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 8
Attachment #542966 - Flags: review?(dao)
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
Resolution: FIXED → ---
Assignee: fryn → nobody
Target Milestone: Firefox 8 → ---
Depends on: 674925
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) (
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: parity-chrome
Blocks: 1637238
Type: defect → enhancement
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.