442058 - Dragging link to existing tab forces focus away from current tab with no way to override in about:config (mDragOverDelay in tabbrowser.xml)

Status: NEW

(Firefox :: Tabbed Browser, defect)

Description

[dfgies]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

When dragging a link to an existing tab, focus is forced away from the current tab after 350 milliseconds.  Previous behavior in FF2 was to keep focus indefinitely on the current tab.  The old behavior is desirable as it allows the user time to consider which old tab to reuse, or whether to create a new tab.

The new behavior is counter intuitive: If a user wants to switch focus to the new link, they'd probably open it in their current tab.  Dragging a link to an existing tab is a way to pre-load a page to view after finishing the current one.

If the new behavior is kept as the default, it should be possible to revert to the old tab behavior, perhaps through a setting in about:config.  This is not possible at the moment as it is being hard-coded in the field mDragOverDelay of tabbrowser.xml

Reproducible: Always

Steps to Reproduce:
1. Open 2 tabs.
2. Load a page in the first tab.
3. Drag a link from tab 1 to tab 2 and hover for more than 350 milliseconds
Actual Results:  
Focus switches to tab being hovered over
No method to change setting.

Expected Results:  
Focus remains in current tab.
Option to change default focus behavior.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Confirmed with Firefox 3 on Windows XP. Regression range is:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-10-20+21%3A00&maxdate=2006-10-21+14%3A00
which points to Bug 248612.

Comment 2

[Dão Gottwald [:dao]]

This is an intentional change.

(In reply to comment #0)
> The old behavior is desirable as it allows
> the user time to consider which old tab to reuse, or whether to create a new
> tab.

The new behavior doesn't defeat this. It's not like you couldn't move your mouse away after the hovered tab got focus.

Comment 3

[dfgies]

Yes you can move away from that tab, but if you release the mouse anywhere but the previously active tab, the active tab will switch to wherever you drag the link to.  

There is no way to open the link in an existing tab WITHOUT switching to that tab unless you do it in under 350ms.

Comment 4

[Dão Gottwald [:dao]]

(In reply to comment #3)
> There is no way to open the link in an existing tab WITHOUT switching to that
> tab unless you do it in under 350ms.

So... why is that a problem?

Comment 5

[dfgies]

(In reply to comment #4)
> So... why is that a problem?

Focus should not switch without being actively selected by the user.  "Sloppy focus" is not the standard in Windows or Mac UIs.  Hovering a UI element generally results in highlighting or a tool tip, not a new window taking over. 

Comment 6

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #5)
> Focus should not switch without being actively selected by the user.  "Sloppy
> focus" is not the standard in Windows or Mac UIs.  Hovering a UI element
> generally results in highlighting or a tool tip, not a new window taking over.

That's true for normal mouse movements, sure, but that's usually not the case for drags (e.g. dragging a file from your desktop to a minimized Explorer window in the taskbar).

The new behavior makes it possible to drag text from one tab to another, for example. I think the win there is greater than the downside of not being able to drag things to background tabs without raising them.

Comment 7

[arni2033]

I find it very uncomfortable too. An easy solution could be to open a link into new tab without switching to it, if you hold Accel(Ctrl), but possible solutions to this were never considered, right?