Closed Bug 296970 Opened 20 years ago Closed 20 years ago

Drag-and-drop of background tab changes focus

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: bugzilla, Unassigned)

References

Details

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
Closed: 20 years ago
Resolution: --- → WONTFIX
I second this request.. :) I rather keep the focus on the page that I'm reading.
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
*** Bug 299921 has been marked as a duplicate of this bug. ***
*** Bug 300701 has been marked as a duplicate of this bug. ***
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. ***
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?
another vote here, but seems too late... already marked as WONTFIX...
*** This bug has been confirmed by popular vote. ***
Ever confirmed: true
*** Bug 319041 has been marked as a duplicate of this bug. ***
Is this not going to be changed? I also expect the dragged tab not to steal focus.
Another vote for this; as people above said.
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
I have also had success with the FLST addon running 3.0b4. Thank you, Michael.
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.
See Also: → 1847407
You need to log in before you can comment on or make changes to this bug.