Closed
Bug 311607
Opened 19 years ago
Closed 19 years ago
"Select new tabs opened from links" pref isn't obeyed for links dragged to existing tabs
Categories
(Firefox :: Tabbed Browser, defect)
Firefox
Tabbed Browser
Tracking
()
VERIFIED
FIXED
Firefox1.5rc1
People
(Reporter: tyl2, Assigned: Gavin)
References
()
Details
(Keywords: fixed1.8, regression)
Attachments
(1 file)
1.55 KB,
patch
|
asaf
:
review+
asa
:
approval1.8rc1+
|
Details | Diff | Splinter Review |
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•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → 1.5 Branch
Assignee | ||
Updated•19 years ago
|
Assignee: nobody → gavin.sharp
Keywords: regression
Assignee | ||
Comment 1•19 years ago
|
||
This is a regression from the tab-drag&drop bug.
Assignee | ||
Comment 2•19 years ago
|
||
Revert to pre tab drag&drop behavior.
Attachment #198973 -
Flags: review?(bugs.mano)
Comment 3•19 years ago
|
||
Comment on attachment 198973 [details] [diff] [review]
patch
r=mano
Attachment #198973 -
Flags: review?(bugs.mano) → review+
Assignee | ||
Updated•19 years ago
|
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
Assignee | ||
Comment 4•19 years ago
|
||
Trunk: mozilla/toolkit/content/widgets/tabbrowser.xml; new revision: 1.117;
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 5•19 years ago
|
||
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?
Updated•19 years ago
|
Flags: blocking1.8rc1?
Target Milestone: --- → Firefox1.5
Comment 6•19 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-
Assignee | ||
Updated•19 years ago
|
Flags: blocking1.8rc1?
Target Milestone: Firefox1.5 → Firefox1.6-
Comment 7•19 years ago
|
||
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?
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•19 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-
Assignee | ||
Comment 10•19 years ago
|
||
(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
Comment 11•19 years ago
|
||
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•19 years ago
|
Attachment #198973 -
Flags: approval1.8rc1- → approval1.8rc1?
Comment 12•19 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
Comment 13•19 years ago
|
||
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•19 years ago
|
Attachment #198973 -
Flags: approval1.8rc1? → approval1.8rc1+
Updated•19 years ago
|
Flags: blocking1.8rc1? → blocking1.8rc1+
Assignee | ||
Comment 14•19 years ago
|
||
mozilla/toolkit/content/widgets/tabbrowser.xml; new revision: 1.103.2.12;
Thanks!
Updated•19 years ago
|
Target Milestone: Firefox1.6- → Firefox1.5rc1
You need to log in
before you can comment on or make changes to this bug.
Description
•