If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

"Select new tabs opened from links" pref isn't obeyed for links dragged to existing tabs

VERIFIED FIXED in Firefox1.5rc1

Status

()

Firefox
Tabbed Browser
VERIFIED FIXED
12 years ago
6 years ago

People

(Reporter: tyl2, Assigned: Gavin)

Tracking

({fixed1.8, regression})

Trunk
Firefox1.5rc1
fixed1.8, regression
Points:
---
Bug Flags:
blocking1.8rc1 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

There's an option to "Select new tabs opened from links." However, I want
basically the same feature if the destination tab is already open. In previous
versions of Firefox, I've been able to set the option to do so. v1.5 beta 1
seems to have taken that option away.

Reproducible: Always

Steps to Reproduce:
1. Load a webpage with selectable links, eg. my.yahoo.com (first tab).
2. Open new tab (second tab).
3. Select (go back to) the first tab.
4. Drag any link from first tab to second tab. Release mouse button.

Actual Results:  
Focus remains on first tab. Second tab, which is now loading a new page, remains
in the background.

Expected Results:  
(Given the appropriate customizable option), second tab should be brought to
focus/foreground when mouse button's released.

Again, I realize the developers may prefer the current behavior (though I'd be a
bit surprised). But at least give us the option so we don't have to click on the
tabs every time.

I'm filing this under minor bug rather than enhancement because it's a
previously available feature that's been lost, whether by chance or choice.

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → 1.5 Branch
Assignee: nobody → gavin.sharp
Keywords: regression
This is a regression from the tab-drag&drop bug.
Created attachment 198973 [details] [diff] [review]
patch

Revert to pre tab drag&drop behavior.
Attachment #198973 - Flags: review?(bugs.mano)
Blocks: 179656
Comment on attachment 198973 [details] [diff] [review]
patch

r=mano
Attachment #198973 - Flags: review?(bugs.mano) → review+
No longer blocks: 179656
Blocks: 249136
Status: NEW → ASSIGNED
Summary: Cannot automatically select existing tab by dragging link to it → "Select new tabs opened from links" pref isn't obeyed for links dragged to existing tabs
Trunk: mozilla/toolkit/content/widgets/tabbrowser.xml; new revision: 1.117;
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Comment on attachment 198973 [details] [diff] [review]
patch

This is a very safe regression fix that just reverts to the 1.0.1 branch
behavior.
Attachment #198973 - Flags: approval1.8rc1?
Flags: blocking1.8rc1?
Target Milestone: --- → Firefox1.5

Comment 6

12 years ago
Comment on attachment 198973 [details] [diff] [review]
patch

not serious enough to take the risk this late in the game.
Attachment #198973 - Flags: approval1.8rc1? → approval1.8rc1-
Flags: blocking1.8rc1?
Target Milestone: Firefox1.5 → Firefox1.6-
Comment on attachment 198973 [details] [diff] [review]
patch

this is very safe, and accidental breaking of UI functionality isn't
acceptable, period.
Attachment #198973 - Flags: approval1.8rc1- → approval1.8rc1?
(Reporter)

Comment 8

12 years ago
I think this is more serious than breaking the "Select new tabs opened from
links" pref, which I think everyone would agree would be unacceptable. Besides,
it breaks expectations of how tabs work. So I really hope it's fixed by 1.5
rather than waiting till the indeterminate release of 1.6.
Severity: minor → normal

Comment 9

12 years ago
Comment on attachment 198973 [details] [diff] [review]
patch

This just isn't something we'd stop ship for and it's not the default
configuration for what we ship. The negative side effect is minor.
Attachment #198973 - Flags: approval1.8rc1? → approval1.8rc1-
(In reply to comment #9)
> (From update of attachment 198973 [details] [diff] [review] [edit])
> This just isn't something we'd stop ship for and it's not the default
> configuration for what we ship. The negative side effect is minor. 

The patch is even more "minor". Not fixing a regression from the 1.0 behavior
due to someone accidentally removing code seems like the wrong decision to me,
but I suppose there are bigger things to worry about.
Version: 1.5 Branch → Trunk
Scott, Asa, could you reconsider this patch for the branch? The patch is very
safe  and fixes an accidental UE-regression from the first beta. It's baking on
the trunk for about a week now.
Flags: blocking1.8rc1?

Updated

12 years ago
Attachment #198973 - Flags: approval1.8rc1- → approval1.8rc1?

Comment 12

12 years ago
Asaf, if you can get a verification on the trunk and some testing around tab
behaviors to make sure that nothing else regressed from this change, we'd
reconsider.
Keywords: qawanted
verified on Mac and Windows trunk builds from 1017 
I also did a little testing around the pref and things seem to be fine.
Status: RESOLVED → VERIFIED

Updated

12 years ago
Attachment #198973 - Flags: approval1.8rc1? → approval1.8rc1+

Updated

12 years ago
Flags: blocking1.8rc1? → blocking1.8rc1+
mozilla/toolkit/content/widgets/tabbrowser.xml; new revision: 1.103.2.12;

Thanks!
Keywords: qawanted → fixed1.8
Target Milestone: Firefox1.6- → Firefox1.5rc1
You need to log in before you can comment on or make changes to this bug.