The default bug view has changed. See this FAQ.

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

REOPENED
Unassigned

Status

()

Firefox
Tabbed Browser
REOPENED
7 years ago
a year ago

People

(Reporter: eyal gruss (eyaler), Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {polish, ux-control, ux-efficiency})

Trunk
x86
All
polish, ux-control, ux-efficiency
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: parity-chrome)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

7 years ago
dragging a tab to a new window should focus that window before drop, in order to allow inserting the tab in the desired place.
(Reporter)

Updated

7 years ago
Blocks: 565510
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: ? → -
Keywords: polish, ux-control, ux-efficiency

Comment 4

6 years ago
Created attachment 539673 [details] [diff] [review]
Patch v1

Updated

6 years ago
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

Comment 7

6 years ago
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

6 years ago
Created attachment 542368 [details] [diff] [review]
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.
Attachment #539673 - Attachment is obsolete: true

Comment 9

6 years ago
Created attachment 542369 [details] [diff] [review]
Patch v2

Last patch killed a newline.
Attachment #542368 - Attachment is obsolete: true

Updated

6 years ago
Depends on: 465186

Comment 10

6 years ago
Created attachment 542966 [details] [diff] [review]
Patch v3

Patch has been updated and tests have been added.
Attachment #542369 - Attachment is obsolete: true
Attachment #542966 - Flags: review?(dao)

Updated

6 years ago
No longer depends on: 465186
Comment on attachment 542966 [details] [diff] [review]
Patch v3

This patch seems to conflict with bug 455694...

Comment 12

6 years ago
(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

6 years ago
The patch for bug 455694 now fixes this too.
Depends on: 455694

Comment 14

6 years ago
Fixed by patch in bug 455694.
Assignee: nobody → fryn
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 8

Updated

6 years ago
Attachment #542966 - Flags: review?(dao)
verified on Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0
Status: RESOLVED → VERIFIED
(Reporter)

Comment 16

5 years ago
this is broken in 12.0b1, probably due to 455694 backout
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Updated

5 years ago
Assignee: fryn → nobody
Target Milestone: Firefox 8 → ---
(Reporter)

Updated

5 years ago
Depends on: 674925

Comment 17

4 years ago
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)
You need to log in before you can comment on or make changes to this bug.