Add hidden preference for turning off tab jumpback

VERIFIED FIXED in Camino1.5

Status

Camino Graveyard
Tabbed Browsing
--
enhancement
VERIFIED FIXED
11 years ago
11 years ago

People

(Reporter: Chris Lawson (gone), Assigned: froodian (Ian Leue))

Tracking

({verified1.8.1})

unspecified
Camino1.5
PowerPC
Mac OS X
verified1.8.1

Details

(URL)

Attachments

(1 attachment)

1.97 KB, patch
Chris Lawson (gone)
: review+
Mike Pinkerton (not reading bugmail)
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

11 years ago
Set your prefs to:

Cmd-click opens a new tab
New windows/tabs open in background

Cmd-click a few of the links on the above URL (although it shouldn't be in any way specific to that site). Then Cmd-shift-click a link -- it opens in a new foreground tab.

OK, that's fine. Now close that tab.

In trunk builds, you jump back to the tab in which you clicked. In 1.0.x builds, the *previous* tab (immediately to the left) is activated.

Unless I missed something, this was not a desired behaviour change and is definitely a regression from 1.0.x. I'm pretty sure this happened sometime in the last month, but right now the smallest window I can give is "since 1.0 branched off".
Isn't this just tab jumpback? You're jumping back to the tab you came from?
(Assignee)

Comment 2

11 years ago
This is expected behavior with tab jumpback.  However, I believe that pink verbally endorsed a hidden pref for turning off jumpback, so I'm morphing this bug to that.
Assignee: nobody → stridey
Severity: normal → enhancement
Keywords: regression
Summary: Cmd-shift-click on links results in improper tab close sequence → Add hidden preference for turning off tab jumpback
(Assignee)

Comment 3

11 years ago
Created attachment 229541 [details] [diff] [review]
Patch

Creates camino.enable_tabjumpback and sets it to true by default.
Attachment #229541 - Flags: review?(hwaara)
(Reporter)

Updated

11 years ago
Attachment #229541 - Flags: superreview?(mikepinkerton)
Attachment #229541 - Flags: review+

Comment 4

11 years ago
The question is if we want prefs (hidden or not) for every behavior change we make...
Have people complained about this?  (After the bugs I filed on it were fixed, that is?)  I really think that the behavior we have really is done just right (since those bugs were fixed).
(Assignee)

Comment 6

11 years ago
Well, cl's use case seems like a pretty reasonable one: Open a list of links in the background, open the last of the list in the foreground, then work your way back.

We haven't received many complaints, but the majority of our user-base hasn't ever used a build with jumpback yet.  If people really think it's an unreasonable feature, we can wait for alpha/beta releases and see if we get complaints, but I think wanting to turn off jumpback is a reasonable wish.
i don't think we want a ui pref for this. we need to get the behavior correct and stick with it. a hidden pref......well ok, but it should just work. My daily-use build doesn't have jumpback and god it's annoying now that i know the difference.
Comment on attachment 229541 [details] [diff] [review]
Patch

sr=pink
Attachment #229541 - Flags: superreview?(mikepinkerton) → superreview+
(Assignee)

Updated

11 years ago
Whiteboard: [needs checkin]
(Assignee)

Updated

11 years ago
Attachment #229541 - Flags: review?(hwaara)

Comment 9

11 years ago
Fixed trunk and branch.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [needs checkin]
(Assignee)

Updated

11 years ago
Status: RESOLVED → VERIFIED
(Assignee)

Updated

11 years ago
Keywords: verified1.8.1
(Assignee)

Updated

11 years ago
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.