Drag-and-drop of background tab changes focus

RESOLVED WONTFIX

Status

()

Firefox
Tabbed Browser
RESOLVED WONTFIX
13 years ago
5 years ago

People

(Reporter: Oakwine, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050607 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050607 Firefox/1.0+

Using the now-built-in drag-and-drop capabilities in Firefox (see <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=179656">Bug 179656 - Allow
drag-and-drop reordering of tabs</a>).  When I try to change the tab position of
a tab that is in the background, the tab is focused on mousedown (see <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=295721">Bug 295721 - focused
tabs in tabbox behaviour tweaks</a>).

Reproducible: Always

Steps to Reproduce:
1. Open www.google.com in the first tab
2. Open www.yahoo.com in a second tab
3. Focus the second tab (Yahoo).
4. Drag the first tab (Google) to a new position so that it follows the second
tab (Yahoo).

Actual Results:  
The Google tab has focus.

Expected Results:  
The Yahoo tab has focus.

I understand from the comments 5 and 6 in Bug 295721 that the mousedown focus
was the intended behavior.  However, I believe that they did not consider the
effect that this change would have on Bug 179656, and therefore I have filed
this bug to request a change.
I never get tired of the assumption that because a result doesn't match
someone's expectations, it couldn't have possibly been considered.

Yeah, this changes behaviour compared to miniT on 1.0, but this bit of function
wasn't enough to deviate from how native tab widgets work on all of our major
platforms.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
I second this request.. :)
I rather keep the focus on the page that I'm reading.

Comment 3

13 years ago
I third it.
I also think the assumption made is correct.

If a user wanted focus, he would click on the tab.
It's counter intuitive to change focus to something a user is draging and dropping.

The same goes for dragging and droping the tab that currently has focus, the
focus stayes.

I'm not saying your wrong Mike, but this should be considered a bit more, and
perhaps we could conduct a usibility study to find out what indeed does work out
best for the user.
Would be marvellous if the choice focus or not was an extra option in about:config 

Comment 5

13 years ago
*** Bug 299921 has been marked as a duplicate of this bug. ***
*** Bug 300701 has been marked as a duplicate of this bug. ***

Comment 7

13 years ago
why would you want to focus your page while being in a re-ordering process?

mike could you define 'how native tab widgets work on all of our major
platforms'?
*** Bug 302435 has been marked as a duplicate of this bug. ***

Comment 9

12 years ago
Another vote for the change (or at least for an option in about:config). 
Drag-and-drop changes the way people utilize tabs, and stealing focus on
mousedown breaks the new interaction.  Not only that, but the Unread Tabs
extension (https://addons.mozilla.org/extensions/moreinfo.php?id=631) is
severely crippled; one loses the ability to rearrange unread tabs because moving
a tab marks it as "read".  AFAICT, this problem (reordering unread/background
tabs) is impossible to fix as long as tabs focus on mousedown.

P.S. Is Bug 296980 a duplicate of this one?

Comment 10

12 years ago
another vote here, but seems too late... already marked as WONTFIX...

Comment 11

12 years ago
*** This bug has been confirmed by popular vote. ***
Ever confirmed: true
*** Bug 319041 has been marked as a duplicate of this bug. ***

Comment 13

12 years ago
Is this not going to be changed?

I also expect the dragged tab not to steal focus.

Comment 14

12 years ago
Another vote for this; as people above said.

Comment 15

10 years ago
The FLST extension <http://gorgias.de/mfe/> fixes/works around this for me on recent trunk. An undocumented, inadvertent feature, I think.

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9b5pre) Gecko/2008032608 Minefield/3.0b5pre - Build ID: 2008032608

Comment 16

10 years ago
I have also had success with the FLST addon running 3.0b4. Thank you, Michael.

Comment 17

8 years ago
Tabberwocky <https://addons.mozilla.org/firefox/addon/14439> also works around this with a visible preference and feature by suppressing the mousedown event listener and instead calling the same function on click.

Updated

7 years ago
Duplicate of this bug: 614154
You need to log in before you can comment on or make changes to this bug.