Closed Bug 159266 Opened 22 years ago Closed 14 years ago

Bookmark groups should replace tabs smartly rather than append

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: cmaximus, Unassigned)

References

Details

I outlined a counterproposal to bug 153016 (which itself was a counter to bug
134800) which should be a bug in its own right.

I'll copy that proposal and some relevant comments here.

Combined with a few other sly tweaks - like rt.clicking to open a group of tabs
in a new window and dragging a group to the tabbar or an empty tab to
open+append them, I think this proposal forms a coherent and complete sol'n to
the Bookmark Groups into Tabs connundrum.

---begin copy---
------- Additional Comment #16 From claudius@netscape.com  2002-07-17 16:06 -------

I think we were really close to the correct behavior way before we went and
changed everything. There was a bug that needed fixing - but we didn't have to
go and fundamentally change the way tabs open.I recognize we needed a quick fix
to satisfy the upcoming release, but let's not try to shoehorn the quickfix in
permanently. Let's go back and simplify everything. Here's a sol'n that keeps
things damn near the way they were (which seemed intuitive to me) but of course
doesn't destroy tabs.

I'll describe two scenarios: first, you have 2 open tabs and you open a group of
3, and secondly you have 3 open tabs and you open a group of 2. The single
tab/bookmark case works exactly the same way(as it should, right Hixie) so no
need to address it specifically.

Scenario 1: Two tabs open and pref set to open tabs in background.[this tab has
focus]. You click a group of 3 tabs.

Before:    Tab1    [Tab2]
After:   NewTab1   [NewTab2]   NewTab3

This is just like clicking a bookmark, when you load it, it replaces the page
you're looking at. If you want that old page back - click 'back', there's no
dataloss.

Scenario2: 3 tabs open, pref set for background, click group of 2

Before: Tab1    [Tab2]    Tab3
After: NewTab1  [NewTab2] Tab3

There's nothing magic or fancy here. The reason it's easy to explain is because
it straightforward and consistent. There are no(or not many) 'if's and 'and's.
The metaphor i see is dealing out a card game. Just deal out the tabs starting
from the left. With consitentcy comes understanding.

The only subtlety in my plan is that the current pref for 'open tabs in
background' would serve a dual role. Without it set, focus would always revert
to the leftmost(first) and newly opened tab([NewTab1]).

This is a different proposal and should techincally be in a different bug, but i
promised to deliver a BookmarkGroup Manifesto. so here it is. One could
summarize this idea as "Bookmark groups should replace smartly rather than append".


------- Additional Comment #17 From jag (Peter Annema) 2002-07-17 21:28 -------

I like this a lot (I've suggested it a couple of times, mostly offline). I seem
to recall though that some people thought there were problems with this too
(users not able to find that ready-to-submit form that is now hiding behind the
back button in one of the tabs). Caillon, do you remember?

cc'ing marlon and lori who were part of the discussion that led to "always append".


------- Additional Comment #18 From Christopher Aillon 2002-07-17 21:46 -------

The two proposed scenarios are for pref settings that aren't even the default. 
Granted, we need to make this work regardless of the prefs, but what are the
proposals for when the "Load tabs in background" preference is turned off (the
default value)?  I think we should look at that first, and then see how a
proposed solution there fits with loading in background turned on.


------- Additional Comment #19 From jag (Peter Annema) 2002-07-18 03:01 -------

I think the assumption was made that when the load-in-background pref is off the
first tab of the set is focused (in this case always the first tab in the window):

Scenario 1: Two tabs open, click a group of 3 tabs.

Before:   Tab1      [Tab2]
After:  [NewTab1]   NewTab2  NewTab3

Scenario 2: Three tabs open, click a group of 2 tabs.

Before:   Tab1       Tab2    [Tab3]
After:  [NewTab1]   NewTab2   Tab3


------- Additional Comment #20 From Ian 'Hixie' Hickson (away until August)
2002-07-18 05:54 -------

I strongly disagree with anything that affects tabs other than the one I have
focussed, whether that be to close them or to change what they are pointed at.


------- Additional Comment #21 From Ian 'Hixie' Hickson (away until August)
2002-07-18 05:58 -------

To clarify:

I have bookmark groups with over 40 items in them which I use *regularly*. I
also manually open over 80 tabs (bugzilla bugs that have changed since I last
checked) *regularly*. If I ever open one of the bookmark groups while the bugs
are open, I do NOT want to have to go through hitting the back button 40 times.
Especially considering any of those tabs could have un-cached form content (e.g.
on pages where the form is dynamically generated), which would still lead to
dataloss.

The current behaviour is fine; IMHO an improvement to it would be to replace the
active tab with the first tab of the group (this makes the one bookmark group
simplify to be equivalent to a simple bookmark), and insert the other tabs to
its immediate right, but that is only a minor difference compared to not
clobbering my active tabs.
------------end of copy---------------------
bug 137194 rt.click "open in new window" on a BMGroup in Ptoolbar does the worng
thing.
I notice you didn't take the time to copy/paste any of the counter-arguments to
your specific proposal.  Let me oblige. <grin>

As per bug 153016 comment 22, I am totally opposed to any behaviour where tabs
to the LEFT of the focused tab are replaced.  If I have 4 tabs open with tab 1
focused, and I load a 4 tab group, I would expect all 4 tabs to be replaced. 
However, if I have the *4th* tab focused, I would expect tabs 1-3 to be left
alone, tab 4 to be replaced, and 3 new tabs created.  By opening a tab group I
feel I am explicity telling the browser to open a series of tab "from here".
  
When I have the 4th tab of 4 focused and I load a single bookmark, it doesn't
replace tab 1, it replaces tab 4.  The same analogy should hold for multiple
bookmarks.
Mine
Assignee: ben → caillon
aack! NO!  Please do not modify anything in tabs which aren't focused,
regardless of whether the replaced tabs are to the left or right of the current
one!  Even without dataloss, it would be disorienting and bothersome.

This is even worse than the request in bug 153016, which I also oppose, but not
as strongly.

Maybe we should ask mpt if a pref browser.tabs.tabgroupopenposition would be OK. j/k
(I know this kind of post should be kept in the newsgroups, but c'mon.)

We should probably just morph bug 158365 into "What should clicking on a
groupmark do?" or something.  Having several bugs open, only one of which will
be fixed, the others wontfixed is a bit weird...
Blocks: 159431
None of the 3 "opposing" bugs should be closed or morphed into something else. 
If one of them is eventually checked in, then that will decide the others' fate.
 There is also the possibility that one or more of them can be implemented at
the same time with the use of preferences, accelerators, or other methods of
activating a certain behaviour at a certain time.

See bug 159431.
Blocks: bm-group-tracker
re comment#3 umm, yeah that's exactly why I had to create this bug in the first
place, remember? My comments were counter to your proposal and polluted that bug
so we broke them out. But thanks for muddying this one. My only goal here was to
try to mature and tweak this particular proposal on its own merits.
Depends on: 208278
->jag
Assignee: caillon → jaggernaut
Product: Browser → Seamonkey
Assignee: jag → nobody
QA Contact: claudius → bookmarks
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.