Closed Bug 158365 Opened 22 years ago Closed 20 years ago

group bookmarks should reuse existing tabs instead of opening in new tabs

Categories

(SeaMonkey :: Tabbed Browser, defect)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: jtilak1, Assigned: jag+mozilla)

References

Details

if you already have tabs open, mozilla used to use those tabs to display
bookmark groups. now, it opens NEW tabs for each bookmark in a group. this is
hard to explain, but i will try...

for example: open a new window. (1 blank tab is displayed) load a group with 4
URLs. (4 new tabs are opened. the blank tab is left blank.) in the past, mozilla
would use the blank tab to display one of the URLs and open 3 new tabs for the
other URLs. this made sense. now all groups are opened in new tabs. so if i have
4 tabs open and i load a group with 4 URLs, i will have 8 tabs! when what i
wanted was for mozilla to use the already opened tabs to display the 4 URLs.
bookmark groups are now useless to me because i have to close the old tabs
evertime i load a group.

if this is a new "feature" i like the old way better. are other people having
this problem? im using nightly builds (2002071706) on win2k and have noticed
this only in recent builds. is this a regression? i would hate to have to use
old builds because of this...

*** This bug has been marked as a duplicate of 153016 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
This is not a dupe of bug 153016. That bug still advocates adding new tabs
instead of reusing existing ones (except it suggests adding tabs to the right of
the focused tab instead of after the last tab).

Claudius, did you file a bug on this yet or was there an existing one?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: group bookmarks open in new tabs instead of using tabs already open → group bookmarks should reuse existing tabs instead of opening in new tabs
I would be just as happy with this fix as I would with one for bug 153016. 
Essentially, I don't like the way tab groups work now at all.  I do NOT think
that they should ever be appended at the end.  (Unless you do something like a
Ctrl-Click on a group, if you're ever able to do that with a bookmark, in which
case I would expect that behaviour.)  Both insertion and flat-out replacement
are better ways of handling things.  (Multizilla uses replacement.)  With that
in mind, I'll track this bug also.

FYI, the reason for moving away from the old behaviour was because of dataloss.
 However, IMO, it would have been handled much better if it had been "fixed" so
you could simply click on Back to go back to what the tab that's replaced used
to show, thereby allowing you to retrieve replaced data.  For some reason, this
wasn't considered appropriate.  (Multizilla lets you click Back on each replaced
tab.)

Confirming this bug as an alternative.

However, I should also note that, as per bug 15306 comment 22, I am totally
opposed to any behaviour where tabs to the LEFT of the focused tab are replaced.
 (Such behaviour was mentioned in discussion of bug 15306.)  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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Bug 153016 comment 22.  I hate it when I do that.
Bookmarking tab groups is too useful a feature to hobble by restricting the
subsequent loading behavior. Why not make this a user pref? Either opening a
tabbed group clobbers and reuses all existing tabs, replaces the focused tab and
all tabs to the right of it, or opens all new tabs and doesn't touch existing
ones. Personally, I was happy with the way 1.1a behaved (clobbering and reusing
all existing tabs), but the argument to only reuse the one with focus and those
to the right of it makes sense to me as well.
There are now 3 different bugs open on how the current behaviour should be
changed so, with the current behaviour, that leaves us with 4 different approaches:

1. Always append.
2. Replace current, insert to right.
3. Replace current, reuse to right.
4. Reuse from leftmost on.

I'm following all of these bugs because I have an interest in how tab groups
should work, and I feel that there are merits and detriments to most of these
approaches.  (I don't think there's anything beneficial to 4. at all, but am
still keeping an eye on it.)

Personally, I DO think that it should be a preference since there is no clear
majority opinion and it's obvious that different people want different things. 
I made such a suggestion in bug 153016 comment 6 which I will paraphrase here:

Add a setting to the tab group folder itself, such that it determines the tab
group's behaviour when its sub-tabs are loaded.  Just as we have keywords,
descriptions, and schedules / notify attributes assigned to individual tabs, tab
loading behaviour could be something that's settable in the Bookmark Manager for
each tab group folder.  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.  I also would not like to see yet another
Preferences addition.  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.

After suggesting this the response I got was that there should be no preference
(or configurable behaviour), tab groups should just load in the "correct" way
period.  The problem with that though, as has become increasingly obvious, is
that the "correct" way is not an objective statement since nobody can agree on it.
Thanks, Jason, for listing the tabgroup open options in my order of preference.

While I was joking about a user_pref in 159266, I had forgotton about the
possibility of an additional property attached to the bookmark (folder) itself.
 That seems to make the most sense, if a pref were to be implemented.  But
additional prefs still add complexity to the code...
Blocks: 159431
See new meta bug 159431.
Blocks: bm-group-tracker
> FYI, the reason for moving away from the old behaviour was because of dataloss.
>  However, IMO, it would have been handled much better if it had been "fixed" so
> you could simply click on Back to go back to what the tab that's replaced used
> to show, thereby allowing you to retrieve replaced data.  For some reason, this
> wasn't considered appropriate.  (Multizilla lets you click Back on each replaced
> tab.)

Actually, you could go back to the page that was previously in that tab (though
it seems some people were confused about that and have spread the confusion
since). The only real dataloss was because with 6 tabs open and 4 items in a
bookmarkgroup, we would close the last 2 tabs. It has been suggested that filled
out (but not submitted yet) forms in the first four tabs would be easily lost
after the bookmarkgroup was loaded, which one could also consider dataloss.
*** Bug 159845 has been marked as a duplicate of this bug. ***
In my mind group bookmarks should be treated just as other bookmarks.  If I load
a bookmark in a single window, it will overwrite whatever is there.  Why should
we configure groups to behave any differently?
I agree with you - as least so far as the *first* bookmark in the group is
concerned.  The real difficulty likes in what to do with the remaining bookmarks
in the group.  Since regular bookmarks only *have* a single bookmark, there's no
precedent for dealing with anything other than just the first one.

However, whatever is done with the 2nd, 3rd, etc., bookmarks, I'm totally in
agreement that *at least* the first bookmark should overwrite the contents of
the currently active tab.  Currently, they append to the end of the tab list -
which is wrong on a whole number of levels.  Replacing all bookmarks (this bug)
is certainly better than what we currently have.
I like either option 2 from comment #6 (replace current tab with bookmarked
group,) or replacing all tabs in the current window with the bookmarked group.
Perhaps the latter should be done with a modifier key.
QA Contact: sairuh → pmac
This isn't a huge issue and there are lots of other things that should be taken
care of first.  However I would vote to make it configurable like comment 6
suggests.
My problem with replacing tabs that are already open is that, coming from Opera,
it's totally unexpected behaviour. I suppose that the option reads 'Open in
Tabs', not 'Open in New Tabs', which is really what I'd prefer. When I have tabs
open, the overwhelming likelyhood is that I'm keeping them open and to those
pages for a reason. It never actually occured to me that you'd want to open
something else up in them and then have to page back if you wanted to see those
pages again.

I throw in with the User Preferences idea. Apparently, people are coming into
this situation with very different mindsets. 
*** Bug 164977 has been marked as a duplicate of this bug. ***
I would argue for interface consistency.
Let me give you an example:

When I open 1 single regular bookmark in the same tab, i would left click.
When I open 1 single regular bookmark in a new tab, i would ctrl+/middle click.

Now, if we were to treat a group bookmark as a single element,
and i were to open a group bookmark with a left click, I would expect that all
existing tabs be re-used before any new tabs were to be opened.
Likewise, if i were to open a group bookmark with a crtl+/middle click, i would
expect new tabs to be opened for all individual bookmarks wheather they apend to
the left or the right.
I'm thinking along the lines of comment #15.

If I have tabs open, and I want to open a group, I wouldn't
want existing tabs to be overwritten.

I'd favor a context menu item such as "Open in existing tabs"
for group bookmarks.
OS: Windows 2000 → All
Hardware: PC → All
Note that a patch for bug 203960 has been checked in which impacts this bug. 
That patch removes ALL existing tabs (no matter how many there are) and replaces
them with those of the tab group being opened.  It's not quite a duplicate of
this one, because this bug doesn't necessarily say that if you have 5 tabs open
and open a group of 3, you'll end up with just those 3...

(Currently, the behaviour is hard-coded but, hopefully, will become conditional
on a hidden pref or tabbed browser prefs UI.)
Blocks: 208278
I actually got used to the way Mozilla 1.4 opened a bookmarked tab group.  Is
there a possibility to add that as an option to the preference item under tabbed
browsing?  "Open new tabs reusing currently displayed tabs" vs "Open new tabs in
addition to currently displayed tabs".
See my comment 19 again.  Bug 203960 has not yet been resolved.
Bug 203960 has been resolved fixed (replace all or append as a preference).

How does that affect this bug?  If we have 5 tabs displayed and open a 3-tab
group of tabs what does this specific bug want to have occur?  (It's never been
clearly spelled out.)  If it's to end up with just the new 3, then this bug is
fixed...
*Vote against this bug.
IMO broken behaviour to replace existing tab content from bookmarks.
Maybe add a pref for those who prefer b0rked tab behaviour.
Reviewing this bug.  Nobody responded to my question in comment 22 a year ago
now.  Is the reporter of the bug still following this and, if so, is the current
preference acceptable?

Assuming there is no feedback in favour of keeping this bug open, I think it
should be resolved as fixed by bug 203960.

This bug has caused me to loose work.
Making it significantly less secure than I.E, because it will nuke my data with
little provication
"Fixed" by Bug 203960. Resolving as WORKFORME, although it really doesn't. It's
more like WORKSFORTHEM.

Prog.
Status: NEW → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → WORKSFORME
Verifying, as comment 26 tells.

(In reply to comment #25)
> This bug has caused me to loose work.
> Making it significantly less secure than I.E, because it will nuke my data with
> little provication

Bug 203960 Make bookmark groups conditionally replace existing tabs instead of
appending

bug 203960 comment 30 checkin 2003-05-29
changed loading of groups from adding to replacing tabs.

bug 203960 comment 108 checkin 2003-09-23
created the preference that controls the loading of groups, adding (default) or
replacing tabs.

So if you open Mozilla Suite Preferences->Navigator->Tabbed Browsing, you can
change the behaviour:
When opening a bookmark group
[x] Add tabs
[ ] Replace existing tabs

If you are using Firefox, you can use the less bloated and more comfortable
about:config to change browser.tabs.loadFolderAndReplace
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.