Closed Bug 344958 Opened 18 years ago Closed 18 years ago

Add hidden preference for turning off tab jumpback

Categories

(Camino Graveyard :: Tabbed Browsing, enhancement)

PowerPC
macOS
enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Camino1.5

People

(Reporter: bugzilla-graveyard, Assigned: froodian)

References

()

Details

(Keywords: verified1.8.1)

Attachments

(1 file)

1.97 KB, patch
bugzilla-graveyard
: review+
mikepinkerton
: superreview+
Details | Diff | Splinter Review
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?
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
Attached patch PatchSplinter Review
Creates camino.enable_tabjumpback and sets it to true by default.
Attachment #229541 - Flags: review?(hwaara)
Attachment #229541 - Flags: superreview?(mikepinkerton)
Attachment #229541 - Flags: review+
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).
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+
Whiteboard: [needs checkin]
Attachment #229541 - Flags: review?(hwaara)
Fixed trunk and branch.
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [needs checkin]
Status: RESOLVED → VERIFIED
Keywords: verified1.8.1
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: