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)
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".
Comment 1•18 years ago
|
||
Isn't this just tab jumpback? You're jumping back to the tab you came from?
Assignee | ||
Comment 2•18 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•18 years ago
|
||
Creates camino.enable_tabjumpback and sets it to true by default.
Attachment #229541 -
Flags: review?(hwaara)
Reporter | ||
Updated•18 years ago
|
Attachment #229541 -
Flags: superreview?(mikepinkerton)
Attachment #229541 -
Flags: review+
Comment 4•18 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•18 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.
Comment 7•18 years ago
|
||
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•18 years ago
|
||
Comment on attachment 229541 [details] [diff] [review]
Patch
sr=pink
Attachment #229541 -
Flags: superreview?(mikepinkerton) → superreview+
Assignee | ||
Updated•18 years ago
|
Whiteboard: [needs checkin]
Assignee | ||
Updated•18 years ago
|
Attachment #229541 -
Flags: review?(hwaara)
Comment 9•18 years ago
|
||
Fixed trunk and branch.
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [needs checkin]
Assignee | ||
Updated•18 years ago
|
Status: RESOLVED → VERIFIED
Assignee | ||
Updated•18 years ago
|
Keywords: verified1.8.1
Assignee | ||
Updated•18 years ago
|
Keywords: fixed1.8.1
You need to log in
before you can comment on or make changes to this bug.
Description
•