Last Comment Bug 344958 - Add hidden preference for turning off tab jumpback
: Add hidden preference for turning off tab jumpback
Status: VERIFIED FIXED
: verified1.8.1
Product: Camino Graveyard
Classification: Graveyard
Component: Tabbed Browsing (show other bugs)
: unspecified
: PowerPC Mac OS X
-- enhancement (vote)
: Camino1.5
Assigned To: froodian (Ian Leue)
:
:
Mentors:
http://ntsb.gov/ntsb/AccList.asp?mont...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-17 13:02 PDT by Chris Lawson (gone)
Modified: 2006-08-25 15:13 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Patch (1.97 KB, patch)
2006-07-17 14:17 PDT, froodian (Ian Leue)
bugzilla-graveyard: review+
mikepinkerton: superreview+
Details | Diff | Splinter Review

Description User image Chris Lawson (gone) 2006-07-17 13:02:36 PDT
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".
Comment 1 User image Samuel Sidler (old account; do not CC) 2006-07-17 13:11:44 PDT
Isn't this just tab jumpback? You're jumping back to the tab you came from?
Comment 2 User image froodian (Ian Leue) 2006-07-17 13:38:48 PDT
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.
Comment 3 User image froodian (Ian Leue) 2006-07-17 14:17:34 PDT
Created attachment 229541 [details] [diff] [review]
Patch

Creates camino.enable_tabjumpback and sets it to true by default.
Comment 4 User image Håkan Waara 2006-07-18 06:55:48 PDT
The question is if we want prefs (hidden or not) for every behavior change we make...
Comment 5 User image Smokey Ardisson (offline for a while; not following bugs - do not email) 2006-07-18 11:00:45 PDT
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).
Comment 6 User image froodian (Ian Leue) 2006-07-18 11:44:25 PDT
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.
Comment 7 User image Mike Pinkerton (not reading bugmail) 2006-07-20 06:29:27 PDT
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 8 User image Mike Pinkerton (not reading bugmail) 2006-07-20 06:30:00 PDT
Comment on attachment 229541 [details] [diff] [review]
Patch

sr=pink
Comment 9 User image Nick Kreeger 2006-07-20 20:56:08 PDT
Fixed trunk and branch.

Note You need to log in before you can comment on or make changes to this bug.