Closed Bug 153016 Opened 22 years ago Closed 14 years ago

Bookmark groups should insert rather than append.


(SeaMonkey :: Bookmarks & History, defect)

Not set


(Not tracked)



(Reporter: jasonb, Unassigned)



From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020618
BuildID:    2002061808

(Carried over from bug 134800.)

I think that the focused tab should be replaced by the 1st tab in the
group, and all other tabs in the group inserted between the focused tab and any
other tabs to the right.  This keeps the tabs in a contiguous grouping (which I
don't think anybody really objects to) but keeps the usage of bookmarks
consistent with how single bookmarks work.

With a single bookmark, the currently focused tab is replaced, and a group
bookmark comprised of only one bookmark should behave the same as a regular
bookmark.  I think that group bookmarks should behave as close to single
bookmarks as much as possible (to avoid confusion), but also maintain their
grouping and prevent dataloss.  This seems the most logical way of doing it to
me.  (The back button would then change the focused tab back to what it was
previously, but the other inserted tabs would remain.)

One thing this would address is the very annoying "hanging left tab" syndrome I
now see.  I run Mozilla and immediately open a tab group.  Now I'm left with a
left-most tab that I don't care about and have to always close in annoyance.  If
I *want* to keep all my currently focused tab I'd simply create a new tab,
switch to it, then load my tab group from there.

Reproducible: Always
Steps to Reproduce:
1. Open a group tab.

Actual Results:  Tabs are all appended.

Expected Results:  Focused tab should be replaced by the 1st tab in group,
remaining tabs in group should be *inserted* to the right of the focused tab.
I'd like to vote against this bug. :-}

I like the behavior as it is now.  It is consistant with how single tabs open;
at the end of the current list of tabs.

IMHO, a bookmark group of 1 tab doesn't need to act like a normal bookmark,
because it is a 'group'; distinctly different from a normal bookmark.

Jason, would the ability to use a tabgroup as a 'homepage' make this better for
you?  That would solve the 'empty tab' issue I think. (if I understand your
usage of groups correctly).
BTW, the tabgroup homepage bug is bug 118835
It does little good to file a bug against something "caused" by my fix without
assigning me the bug, or at the least CC'ing me.

Carrying over from 134800, we decided on the append method for now because it is
the least destructive way of doing things.  And let me re-iterate that *we have
no clue what method users prefer here!*  We know for a fact that the old
behavior of clobbering every tab is bad.  The append method is not necessarily
intended to be the optimal solution.  However, to discern what the optimal
solution is requires usability testing.  There are going to be some people that
love this behavior and some that don't.  So, I think for now the decision is
going to be to stick with what we have and if and when we get data that clearly
shows that a different way of doing things is better, we will go with that.  For
now though, it is useless to get into a fight over which way is best as it won't
change anything.

And I strongly recommend looking for newsgroup feedback.  At this point,
opinions on the newsgroup will be invaluable.
Assignee: ben → caillon
Having a tab group as a homepage won't help me, since I certainly don't always
want the tab group loaded when I start the browser.  I only want to have it open
occasionally - and when I do, I open the browser then immediately load the tab
group (then in frustration close the single tab on the left <grin>).

Here's a graphical depiction of exactly why I think that this behaviour is
closest to how single bookmarks work.

Single bookmark (Tab 2 has focus):

 Before: Tab 1    [Tab 2]       Tab 3
 After:  Tab 2    [New Tab 2]   Tab 3

Group bookmark:

 Before: Tab 1    [Tab 2]        Tab 3
 After:  Tab 1    [New Tab 2]    Tab 3
                    Tab 2a
                      Tab 2b
                       Tab 2c

Now, currently we have nothing in place to accomodate "tabs within tabs"
(although I believe that there's some bug open on that too).  So, since we can't
accomodate the "columnar" aspect described above, the only way to represent it
is to "flatten" it out into individual tabs.  (Another possibility along the
lines of tabs within tabs, is to make [New Tab 2] a drop down combo box with the
list of sites included in the bookmark group - you could then pick which site
you want that tab to show at any given time, but have "all sites" still
contained within the single tab...)

In any case, representing the above as closely as possible with what we
currently have in place gives us this:

Tab 1  [New Tab 2]  Tab 2a  Tab 2b  Tab 2c  Tab 3.

Christopher: My apologies for not assigning it to you automatically.  I've never
opened a bug in this situation before and I can now see why not doing as you
suggest might be thought of as a faux pas.
Jason, the argument against what you propose is that it moves existing tabs
around.  Moving things in the User Interface is considered to be a Bad
Thing(tm).  The user has likely already become accustomed to where his/her tabs
are and has a general idea as to the history of each.  With your proposal, the
user now has to think about what tabs are which, where they are, etc.

I originally thought that your proposal was the best way to go about doing this,
and in fact, this behavior was already proposed in bug 134800 by the initial
reporter, but looking back on it, I think the insertion method is very
unintuitive.  While it sounds like a good idea, it is very confusing to use if
you have several existing tabs open.

Also note, that the reporter of bug 134800 originally requested the behavior you
want (Bug 134800 Comment 0), but then retracted that as he was extremely pleased
with the new behavior instead.  (Bug 134800 Comment 40).
I don't think I *personally* agree that moving existing tabs to the right to
make room for a tab group insertion would confuse everybody or even most people.
   Still, I do see your point that it might well confuse SOME people, and we
don't want to do that.  (Perhaps a suggestion would be to make the tabs in a tab
group a different colour, in order to visually draw the eye to them and help
people not lose track of what what's happening?)

In any case, would it not be possible to add a setting to the tab group folder
itself, such that it determines the behaviour of it when it's sub-tabs loaded? 
Just as you have keywords, descriptions, and schedules / notify assigned to
individual tabs, could not append or insert be something that's settable in the
Bookmark Manager for each tab group folder?  (The default could be append.)  At
first I thought of context menus and keyboard accelerators - but that would be
WAY too much of a headache on top of an already confusing array of options.  But
a simple setting in the BM shouldn't be that difficult to accomplish and I don't
think it would add any real UI complexity.
>  make the tabs in a tab group a different colour,
please don't.

> would it not be possible to add a setting to the tab group folder itself,
> such that it determines the behaviour of it when it's sub-tabs loaded? 
it's technically possible, but thankfully our UI people will veto that.
> it's technically possible, but thankfully our UI people will veto that.

Why "thankfully" and how do you know it will be vetod?  (I'm looking for
discussion / explanation here, not just short statements.  If you want the
latter you might as well just close the bug and mark it WONTFIX without comment.
I finally installed Multizilla to see how they handle tab groups. (After backing
everything up.)  It lets you choose between Mozilla's current behaviour, and its
old complete replace (and add if necessary) behaviour but without the dataloss -
  any tab that's been replaced will still let you hit the Back button to go back
to its previous state.

However, I was annoyed enough with its "toy-like" interface, other aspects of
its UI, such as moving the new tab and close tab buttons to a separate toolbar,
and the proliferation of simple UI clutter, that I removed it and went back to
vanilla Mozilla - even though that meant I lost the ability to load tab groups
in, to me, a much better fashion.  Despite Mozilla's lack of this ability, I
still find it to be preferable in its UI simplicity.

I certainly don't want Mozilla's UI turned into the almost nightmarish
proliferation of preferences and toolbars that Multizilla seems to exhibit. 
(Even granting that there may be some people who like it - and those should use
it, but they shouldn't be brought over to Mozilla.)

But I still don't see anything wrong with adding a setting to the properties of
group tab folders that determine the method in which their sub-items are opened
on the tab bar.  Comment 7 seems to indicate that the UI people would veto it -
but it wouldn't add anything to the existing Edit / Preferences menu, it
wouldn't add anything to the existing visual UI during normal browsing
experiences, and, in fact, would help delineate tab group folders from regular
folder in the Bookmark Manager in a helpful fashion.  (Currently, the only thing
that a user notices about them is that they have a different icon.)
*** Bug 156903 has been marked as a duplicate of this bug. ***
I agree with claudius' proposal (namely, this bug). The current behaviour is
definitely better than what we had before, though! :-)
Ah...this is my my proposal, not Claudius'.  He hasn't posted a comment here
yet.  I also checked bug 134800 and, aside from the final comment, couldn't find
find support for this proposal there either.  But, who am I to complain?  I
could use some support here! <grin> Are you in favour of the tab group folder
setting as per comment 6 or did you have something else in mind?
No, I don't support having settings for this, it should just be the behaviour
and that's all. :-)
> it should just be the behaviour and that's all. :-)

Okay, I can go along with that too. <grin>
*** Bug 157411 has been marked as a duplicate of this bug. ***
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

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".
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".
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.
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
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.
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

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.
First of all, this particular bug is about inserting (except for the focused
tab) rather than replacing.

Claudius/Jag: Both of you are suggesting a couple of things that I don't agree
with / feel address this bug.

First of all, you are changing the contents of tabs to the LEFT of the currently
focused tab.  if appending bookmarks is "bad", I don't think that prepending is
any better.  Regardless of whether they should insert, replace, or append to the
RIGHT, I don't think anybody wants tabs to the left to be touched.  When you
load a bookmark you replace the currently focused window - so when you load a
bookmark group you should be replacing everything *starting at* the currently
focused window.  Tabs to the left should be off limits.

Secondly, while I might personally not have a problem with replacing all tabs to
the right, that's not what this bug is about.  Tabs to the right should be
"pushed" more to the right to make room for any more that need to be added. 
Hence the "Insert" description on this bug.

BTW: Whether load in background is on or off, I only EXPECT it to load in the
foreground when I select a bookmark. Currently, we are unable to Ctrl-Click on a
bookmark item which would produce the background load behaviour you suggest. 
(Bookmarks are not fully treated as links.)

If you both want a "Prepend and replace bookmark groups" behaviour you should
open a different bug...
jasonb's right. I did pollute this bug and i personally hate when people do
that. I'll open a new bug, cite the relevant comments, and post the number here.

By the way, it's seems that Jag and I are on the same page here. I thought I'd
forgotten to mention it or something but Jag's comment#19 is exactly what I
meant in the next-to-last paragraph "the only subtlety..." in comment#16.

I think Hixie's experience is nowhere even close to approaching any sort of
typical use case (i believe there are no more than 7 people on the planet who
regulary open 120 tabs :-) - but that's what usability testing is for, no need
to rest solely on my (nor anyone's) beliefs.
No, my usage pattern isn't even close to common. However, considering proposals
in light of extremes (both large and small numbers of open tabs and bookmarks in
bookmark groups) often highlights problems, as I think it does in comment 21.
*** Bug 158365 has been marked as a duplicate of this bug. ***
*** Bug 152335 has been marked as a duplicate of this bug. ***
*** Bug 151788 has been marked as a duplicate of this bug. ***
I'm a little slow with the copy and paste - i did finally file bug 159266
Blocks: 159431
See new meta bug 159431.
In my simple opinion, the behaviour suggested here seems very correct to me. I
personally HATE it if a tab I don't have focused gets affected by the bookmark
groups. I don't care if all I have to do is click the back-button. I'd
constantly be annoyed.

Now I don't know if anyone has thought to check how Opera handles this kind of
behaviour. I think I have to remember you folks that the tabs and bookmark
groups were kind of stolen from them. Their behaviour is the following: They
replace the currently active tab with the first page in the bookmark group. Then
they append all remaining pages in the bookmark group. I'm not at all saying
Opera's the one to follow here, because the behaviour sketched by Jason is the
one I like most. It seems very intuitive. 

Changing the colour of tabs that belong to a bookmark group is something which
I'd be very opposed to. Just doesn't appeal to me. What might be an option( and
I do know this sounds awful :-) ) is flashing the newly opened tabs a second or
two with a colour. 

Just my 198 pennies
> I think I have to remember you folks that the tabs and bookmark groups were
> kind of stolen from them [Opera, ed.]

You might want to read these entries in hyatt's blog:

The short of it is that he looked at what the MultiZilla people had done (who in
turn had gotten their idea from NetCaptor) and wrote his own version of this
concept. Opera didn't have tabbed browsing until after this feature appeared in
Mozilla nightlies (MDI != tabbed browsing, see the first link).

As for the bookmark group idea, it's a pretty obvious one, we didn't need to
look at Opera to come up with it (in fact, I didn't even know they also have
this feature).
*** Bug 173115 has been marked as a duplicate of this bug. ***
Bug 173115 is not a duplicate of this one.  It doesn't want to insert anything
anywhere.  It simply wants to do away with the left-most "dangling" tab that
serves no purpose when opening a bookmark group with only a single tab in place.
*** Bug 179442 has been marked as a duplicate of this bug. ***
*** Bug 159104 has been marked as a duplicate of this bug. ***
Bug 184660 (which I submitted) is *almost* a dupe of this one; I was submitting
the case of a multiply-tabbed Home setting on top of a single open tab. After
reading the comments here, I feel that's sort of a subcase of this bug, and I'd
like to comment (from the user perspective; I've never done any active Moz
development) that I stronly agree with Ian Hickson's comment 20 and comment 21
above. I'd further suggest that newly *inserted* tabs resulting from selection
of a multiple-tab bookmark should be colored differently -- but only until one
of them is focused. This alerts the user to the insertion, preventing the
confusion described in comment 5. 
I'm not sure if I agree with different tab colouring or not - although I do
agree that some kind of visual indication of what was inserted might be
appropriate.  Having said that, if it's not colour I'm not sure what it should
be.  A different tab icon?  Maybe that would be sufficient and not so totally
distracting as I feel a different colour might be.  (If it is colour that
determines it, it should be a subtle shade difference and not something like
bright pink! <grin>)

Also, I'm not sure if any further progress on how to handle bookmark groups when
there are already a lot of tabs open (inserting / replacing / appending, etc.)
can *really* be considered until bug 155325 is resolved.  Presumably, a
determination of working visual cues of new/old tabs would depend on how tab
overflow is handled (and whether a certain methodology works with it or not). 
(For instance, consider bug 155325 comment 32. Should that be implemented (it's
doubtful but possible) then inserting a bookmark group could actually result in
the insertion of a tab row, keeping the "new" group discrete from the rest...)

Alternatively, we can just try to come up with the behaviour in the current
scheme and leave visual cues and/or interaction with tab overflow to later,
additional bugs.
> [..] some kind of visual indication of what was inserted might be
> appropriate.  Having said that, if it's not colour I'm not sure what it should
> be.  A different tab icon?  Maybe that would be sufficient and not so totally
> distracting as I feel a different colour might be.  (If it is colour that
> determines it, it should be a subtle shade difference and not something like
> bright pink!

I was kinda thinkin' of international orange blinking to deep violet, say at
about 10 cycles/second. (Kidding!) Actually, I sort of envisioned a convex
shading, but that might be too much work.

A different tab icon is a good idea too, maybe a dotted outline or a temporary
pair of icons showing the insertion endpoints, i.e: 

(starting condition)
|___________   ____________ +---------------+ ______________   ______________ |
||tab 1     | |tab 2       ||tab 3 (active) ||tab 4         | |tab 5         ||
|---------------------------+               +---------------------------------|
|                                                                             |

(inserting group of 3 [possibly animated] tabs growing in the middle?):
|________  _________ +------------+ ___________  ____________  ______________ |
||tab 1  ||tab 2    ||tab 3 (act) ||<-#|###|#->||tab 7 (old4)||tab 8 (old5)  ||
|--------------------+            +-------------------------------------------|
|                                                                             |

(finished inserting 3 tabs, waiting for user to focus one of them):
|________  _______ +------------+ ________  _______  ________  ______  ______ |
||tab 1  ||tab 2  ||tab 3 (act) ||<-#tab 4||#tab 5#||tab 6#->||tab 7 ||tab 8 ||
|------------------+            +---------------------------------------------|
|                                                                             |

(end state -- user has focused one of the new tabs):

|________  _______  _______  _______ +------------+ _______  _______  _______ |
||tab 1  ||tab 2  ||tab 3  ||tab 4  ||tab 5 (act) ||tab 6  ||tab 7  ||tab 8  ||
|------------------------------------+            +---------------------------|
|                                                                             |

Ghu, ascii-art, sorry. 

Obviously, inserting N tabs into an already-"full" tab row should cause the
endmost N tab(s) to flow to whatever solution is implemented for bug 155325.
Depends on: 155235
Depends on: taboverflow
No longer depends on: 155235
Depends on: 208278
Assignee: caillon → jaggernaut
OPTIONS.  Please, simply (although it may be hideously difficult to implement)

One can include multiple types of tabbed behaviour options in the preferences
dialogue.  It would also be useful if this behaviour could be assigned to
individual accounts, as with other preferences.

I personally MUCH prefer new tab groups to be appended to the right of all my
existing tabs, as it was in Mozilla 1.4.  As it happens, I'm sumitting this in
shock after having a tab group unexpectedly wiped out before my eyes.  The
"Back" button behaviour was something I'd never considered or investigated, but
upon reflection appears too kludgy to be of much use.

The only thing I'd change is when creating a single new tab.  That feels
intuitively like it should appear directly to the right of the focused tab,
wherever that may be in the row of oopen tabs, but again, please give people the
ability to choose tab behaviour, even if it means editing about:config or
something arcane like that.

In the spirit of intuitiveness, the contextual menu that pops up in an empty tab
area should (dynamically) have "New Tab" as the first item in the list.  I
realise this means that it might also have to apply to contextual menus popped
up over existing tabs (for consistency), but if data destruction is so
abhorrent, why are the first two items in the list "Close Tab" and "Close Other

Are there any other bug reporting rules I can break?

Options is what we need.  That's all I'm saying.

This bug is NOT about restoring 1.4's append behaviour.  It's not about
appending at all.  Rather, it's about *inserting* any tabs in tab groups loaded
between the current tab and any tabs that might exist to the right.

For discussion of restoring 1.4's behaviour via a pref, please see bug 203960.
Another vote against this bug...

(In reply to comment #0)
> Expected Results:  Focused tab should be replaced by the 1st tab in group,

Why should it? The focused is likely to be the one the user is reading.
Replacing/covering the currently read content with a different one would mimic
the annoyance of a popup window. 

BTW, for some reason recent 1.8x trunk builds switch to the first tab in the
group. I find that highly annoying, for the very same reason. Is this reported
in bugzilla?

> remaining tabs in group should be *inserted* to the right of the focused tab.

A UI that keeps moving things around defeats user orientation and muscle-memory.
See Microsoft's obnoxious "personalized menus".

*Vote against this bug.
Inserting rather than appending seems brain damaged and counter-intuitive.
When adding paperwork to an in-tray, do you lift all the sheets up and place the
new ones underneath? No. When writing in a diary, do you insert new pages at the
front and add to those? No. That's what you are asking for with "inserting".
This seems very Microsoftian, that is the way Outlook [Express] works with email.
To have tabs open in anything other than chronological order of creation would
be brain-dead. At worst, a pref could be added to accomodate the illogical
Product: Browser → Seamonkey
Beryan's arguments against make no sense. The tab bar is not in the least bit
analogous to a stack of papers: in a stack, only the topmost is accessible and
reaching any other page requires searching back; in the tab bar, all tabs are
equally accessible, which is much closer to how a filing cabinet works (and tabs
are even meant to simulate the label tabs sticking up out of files in a drawer,
as seen end-on) and files are inserted in drawers all of the time.

Besides, if this feature is enabled, he can just open a new tab (which would
still be appended to the right end) and open the group there to get the same
behavior he's used to. This would make bookmark groups more flexible, not merely
Assignee: jag → nobody
QA Contact: claudius → bookmarks
1. On trunk we don't have bookmark groups any more.
2. Left clicking the "Open all in tabs" folder option will only override the current tab. Additional bookmarks will be appended in new tabs.
3. Middle or Control clicking the "Open all in tabs":
3.1. If browser.tabs.opentabfor.middleclick is true, then Ctrl (or Meta) and middle-click:
3.1.1 Opens new tabs, depending on the Shift key and onbrowser.tabs.loadInBackground.
3.1.2 Otherwise if middlemouse.openNewWindow is true, then Ctrl (or Meta) and middle-click opens the folder in tabs in a new window.
3.1.3 Otherwise: See point2.

Closing as INVALID (no bookmark groups) and WORKSFORME (Middle-click options).
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.