Closed Bug 208278 Opened 21 years ago Closed 21 years ago

Loading group of tabs from bookmarks closes all other tabs

Categories

(SeaMonkey :: Tabbed Browser, defect)

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: hhschwab, Assigned: jag+mozilla)

References

Details

(Keywords: dataloss, regression, Whiteboard: *PLEASE NO SPAM* Submit / review / discuss approaches to a patch only.) 

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030604
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030604

Tried loading groups from Bookmark Manager and from folders in Personal Toolbar,
same buggy behaviour. 
Maybe this bug belongs to Component:Bookmarks?






Reproducible: Always

Steps to Reproduce:
1.open some tabs
2.open tabgroup, in a new or old tab
3.old tabs are gone, new are loaded, back button becomes active after load done.

Actual Results:  
All existing tabs were killed, new tabs are loaded.
Going 'Back' loads previous tabs, but always opens first tab.

Expected Results:  
As before, and in 1.4, a tabgroup is loaded in addition to existing tabs.
If not loading in the background: after loading a tabgroup, the backbutton is
disabled, as the new tab doesn´t have a history.

It worked in BuildID 2003052908, regressed in BuildID 2003060104

it still is working in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030603
but not working in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030604
I think this is a deliberate change, but I can't find the bug where I read it.
In any event, you can stop that in preferences by going to about:config and
setting browser.tabs.loadFolderAndReplace to false.
looked at about:config, and had to enter name and value for
browser.tabs.loadFolderAndReplace, false
It didn´t work, so I restartet mozilla, and retried, to no avail.
I then deinstalled Mozilla, and installed the new nightly, to no avail.
The variable persisted, but perhaps it has another name, or doesn´t exist on
Win98, or isn´t boolean (false) but integer (0) ?

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030604
Oh, excellent!  I've been hoping for this change for a long time now.  Odd,
however, that it got implemented without any of the bugs I follow on the subject
being affected.  I'll have to check things out more closely and set some
appropriate dependencies here...

Yes, indeed it does seem to be caused by a checkin (on 5/29) to bug 203960 -
although it was never marked FIXED, which explains why I didn't come across it
during one of my daily checks.

While this makes my day, however, I realise that adversely affects that of other
people.  Yes, there should be a preference for this somewhere, and I don't see
it anywhere.  (Even the summary of bug 203960 indicates that this behaviour
should be conditional.)

In the comments for that bug, jag says the following:

"We should add one or more ways of loading bookmark groups in the background.
Drag & drop of a bookmark group onto the empty space in the tab bar seems good.
I would make dropping onto any of the tabs be treated as a group replace though
for consistency. I actually wouldn't be opposed to adding a visible pref for
append vs replace in the tabbed browsing pref panel."

Also, since the bug is actually closed, it implies that more work / user testing
is still to be done.

I would say that THIS bug should either be marked as a duplicate of bug 203960
(which, if finally resolved properly, should conditionally restore the behaviour
you're looking for) or marked WONTFIX since the current behaviour is intended by
the module owner...



AFAIK, the preference "browser.tabs.loadFolderAndReplace" is Firebird specific
and does not apply to Mozilla.
Same behavior in Moz 2003061508 OSX. If this is intended to be the new default
behavior, there should be a preference to turn it off.

Very annoying when I have a half dozen tabs open and they all get wiped out by a
2 or 3 item bookmark group.
OS: Windows 98 → All
Hardware: PC → All
Identical symptoms to a previous bug:
 bug 134800 - Opening a bookmark group clobbers all open tabs

Other relevant tab group bugs:
 bug 153016 - Bookmark groups should insert rather than append
 bug 159266 - Bookmark groups should replace tabs smartly rather than a...
 bug 158365 - group bookmarks should reuse existing tabs instead of ope...
 bug 184707 - Tab group bookmarks / home groups should overwrite single...
 bug 203960 - Make bookmark groups (conditionally) replace existing tab...
Depends on: 158365
Blocks: bm-group-tracker
Depends on: 203960
Frankie, this bug was caused by 
bug 203960 - Make bookmark groups (conditionally) replace existing tab...
because in this bug the (conditionally) wasn´t honoured.
Before, a group was added to the existing tabs, so you got more and more, if you
didn´t delete some yourself. Now Mozilla deletes all of them for you, before
adding the new tabs.
I was used to load a group of tabs, look at it, and then decide which group to
load additionally, while the first one was still open. I used to use up to three
groups.
But somebody decided tabbed browsing is too complicated .....
So if you want to see multiple sites, add one after one, instead of add one
group after another. That is less complicated.


Adding request for blocking status due to the implementation/fix for Bug #203960
(Make bookmark groups conditionally replace existing tabs instead of appending)
did not implement the "conditional" aspect, and will replace existing open tabs
with no warning to the user.
Flags: blocking1.4+
Did request for blocker wrong....changing to "?" as I should have done.
Flags: blocking1.4+ → blocking1.4?
Adding keywords as this seems to be a regression from Bug #134800, if I
understand that bug correctly now.
Keywords: dataloss, regression
Blocker is not needed. The patch from bug 203960 went in after the 1.4 branch;
the problem only affects the 1.5a nightlies.

If it isn't corrected soon, it should be a blocker for 1.5a though.
Speaking technically (from a b.m.o. perspective), and not taking any "side" on
this issue, I don't believe that either the dataloss or regression keywords are
appropriate.  (Although I understand the sentiment.)

There are certain cases where there is dataloss, but those are being handled by
specific other bugs.  In general (those specific cases aside) you can click on
back to restore your tabs.  This may not be ideal, and it may really bug some
people that it does this now, but "dataloss" is reserved for cases in which you
can never get your data back by normal means.

Also, I'm not sure if regression is appropriate here either.  This isn't really
a bug that's been introduced (where something is unintentionally broken) but a
very specific and intentional change by the module owner - even if it's not
finished yet.
See bug 209290, bug 209294, and bug 209295 for specific cases of dataloss (and
where the keyword makes sense).
Bugs 209290, 209294 and 209295 are examples of the dataloss that is caused by
the fact that opening a tabgroup closes existing tabs (this bug). Hmmm, they
probably should be dups of this bug.

Some of those examples are also mentioned, along with some others, in Bug #203960.

As for "regression", strictly speaking it isn't valid. However, as develepment
work over at Bug #203960 to finish the bug fix seems to have halted, I added the
keyword here in the hopes of kickstarting things again.

Also, from a full read of Bug #203960, I'm removing the 1.4 blocker request, and
will await the 1.5a blocker option to appear.
Flags: blocking1.4?
> [those bugs] are examples of the dataloss that is caused by
> the fact that opening a tabgroup closes existing tabs

No, they are exceptions to the (supposedly recoverable) behaviour that is
intended to occur by having existing tabs close.  The closing of tabs can be
recovered from (except in those specific cases) by clicking on the back button.

The only way that dataloss should be considered here would be if you look at
things from the perspective that those other bugs don't exist, and that clicking
on back *never* restored previous tabs.

> they probably should be dups of this bug.

Not at all.  If they should be, then the summary of this bug should be "Loading
group of tabs from bookmarks causes dataloss", but it isn't.  From what I'm
reading, this bug is not about the dataloss per se, but the fact that the
behaviour of closing other tabs is not desirable.  Dataloss in *some* situations
may contribute to the undesirability of the current behaviour, but it's not the
only objection.

As I said earlier, there is no dataloss from the *intended* behaviour since
you're supposed to be able to click on the back button and regain your old tab
information.  (The tabs are not permanently lost.)  It's only specific,
edge-case scenarios in which dataloss occurs, and those particular instances can
be handled by the other bugs.  (Unless, like I said, you want to morph this one
- but I don't think that was Hermann's intent when he filed this bug.  He's
objecting to replace on general grounds.)

Anyway - it's not a big deal and it doesn't really matter to me what keywords
are listed, so I won't say any more on the subject.
I guess I'll try 1.5 builds again when either bug 203960 is backed out, or a
preference to disable its "feature" is available.
Blocks: 153016, 159266
Flags: blocking1.5a?
*** Bug 211334 has been marked as a duplicate of this bug. ***
There seems to be of disagreement over the correct behavior here, and certainly
not consensus that there's a regression.  (The original idea behind bookmark
groups was certainly that they replace all existing tabs.)  Not a blocker for
1.5alpha.
Flags: blocking1.5a? → blocking1.5a-
It definitely is a regression. Groupmarks are for ordering of groups, and if you
want to combine multiple groups, you are lost. If you want to add a group to
some dynamically generated pages, you are lost.
Before "bug" 203960 was "fixed", you had the power to combine groups as you
wanted to, now you can only load one group, and add single bookmarks thereafter.
Why not make a preference for groupmark-challenged or lazy people to
automatically clear the window before loading a groupmark, and let other do the
deleting themselves, as they know how to, but let them add groups as they want to?
Make it default as it is now, and let people decide if they like to be confused
by having more than one group in the display.
Does "usability" mean to make all knifes blunt, so nobody gets hurt?
Nobody is forced to use groupmarks.
Please read some comments in bug 203960 how groupmarks are used by those people
now missing the old behaviour.
Powerful tabbed browsing and powerful groupmarks are my rerason for using
mozilla, it was a painful regression when 'close other tabs' was removed.
Let Firebird people build the most simple browser of the world, 
also the most extended browser of the world ;-)
don´t cut functionality on mozilla.
> Why not make a preference

Bug 209360 (to make this conditional) is still open - and it's a dependency. 
Once/if a preference is introduced there and it's closed, then this bug will be
fixed.
Hi

Here is my suggestion:

By DEFAULT: Clicking on a groupmark should ADD the tabs to whatever tabs are
currently open, and leave existing tabs alone. 

The should be a CHECKBOX, in the properties of the groupmark properties dialog,
that allows you to set the groupmark to 'Replace all existing tabs with these tabs'.

This is better as there is then a pref on a case-by-case basis, it is
unobtrusive (ie/ doesnt clutter the dialogs people use all the time), and you
dont need to play with about:config prefs

thx

dave
Flags: blocking1.5?
Flags: blocking1.5? → blocking1.5-
*** Bug 217801 has been marked as a duplicate of this bug. ***
I confirm reported behaviour with
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030828

I agree more or less with Dave.

I agree to leave keyword "dataloss", because reported behaviour _causes_ dataloss.

I do not think that it is a regression, IMHO regression means that a buggy
behaviour, that had been fixed, reappeared.

There is no logic in having a warning "do you really want to close all opened
TABs" if I close a window, and on the other hand to overwrite all opened TABs
without warning when I open a group of TABs.

Additionally we should think about rightclick content menu, IMHO:
- missing function "open group in a new window"

Rainer
(as posted on MozZine)

I would like to know the details of this supposed usability testing that lead to
the change. What was the test group the arragement the degree of experience, and
so on.

No details given in any of the before posted bugs.

It is clearly the case that the append behavior is more powerfull as replace can
be easily reproduced, whereas the opposite is not the case.
Also replace destroys information that is not on screen, and is possible Dataloss.

A hidden preference is not acceptable for such an issue, the standard option
needs to be reasonable.

If tabs are to serve as a complete elimination of multi window neccesities, then
it is inaccaptible that an action in the current window destroys all others as well.

If we look at normal bookmark behavior as a guide it replaces not all tabs but
only the current tab.
That's the way it has always been and will always be.
If we see the tab as a replacement for the window it should behave exactly like
that. open a single bookmark loads it in the tab, loading a bookmark group
should load the group in the tab.
To me it seems the most reasonable and consisten behavior would thus be to
replace the current tab and append the other tabs to the right. Then bookmark
group behavior is a logical extrapolation of bookmark behavior.

From this basic behavior the classical append can be reproduced by (New
Tab)->(Bookmark group) and the classical replace by (close all other tabs) ->
(bookmark group)

This is logical consistent and powerfull without being complex.

As someone else noted a single bookmark does not eliminate all other tabs
either. tabs are not only used when browsing one source along multiple paths but
also for coordinating different sources, and to effectively do the later an
effective append like behavior is crucial.
People who only use tabbed browsing for the former might not need this but there
are no reasonable arguments why to save this group of people a single click (or,
if added shortcut) inconsistent behavior is introduced which has the potential
of dataloss as what is perceived as background/out of focus information that
should not be affected by current actions until brought into focus is lost, a
complete way of using the browser is eliminated and the power of tab bookmarks
is significantly reduced.

Consider this: I am writing an email to a fellow student on some research I
looked up the other day, and so I simply click the bookmark group of the
preprints I had found and have all the informationat hand.
I am browsing a board with many messages in different tabs open, and want to
take a short break to check todays online comics. I simply click the bookmark
group and continue reading messages until they are loaded.

Basically tab groups bookmarks help organize bunches of information, and to
append allows one to effectively use this bunches of information.

sure, with multi window management I can still do all that, but that requires me
to introduce another organisation layer which is not neccesary. Thus using the
browser becomes vastly more complex by the current replace behavior.

In summary: There is no reason for it, it brings no reasonable objective
advantages over the replace current tab implementation.

The user expectation argument has to be extremely strong to justify this drastic
step, which I have to repeat it again: completely eliminates a part of tab
functionality without any objective win.

What after people have used tabs for a few days? Do they still not like it? Can
they not be educated? Was the third alternative tested at all?
> To me it seems the most reasonable and consisten behavior would thus
> be to replace the current tab and append the other tabs to the right.

That's bug 153016.
Whiteboard: *PLEASE NO SPAM* Submit / review / discuss approaches to a patch only.
*** Bug 218489 has been marked as a duplicate of this bug. ***
Just to add some Default User point of view:
Whne opening such a group of tabs most logical is to change current, and append
other on the end.
There shoudl be a new entry in <Config> --> Tabbed Browsing stating:
Groups of tabs loading:
-Remove all and load bookmaked
-Load on current, append rest <default>
-Append all
Also it woudl be nice to add:

Bookmark loading:
-Append
-Change current
*** Bug 219709 has been marked as a duplicate of this bug. ***
*** Bug 219800 has been marked as a duplicate of this bug. ***
Fixed by fix for bug 203960 now that the "conditional" part of the bug is
checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Hurrah, I can finally update to 1.5 builds!
Status: RESOLVED → VERIFIED
I've just got 1.5RC1, and either I'm blind, or I can't find an option to change
this replace behavior to appent behavior. 
> I've just got 1.5RC1

The patch wasn't checked in until after RC1 was release.  It will be in RC2.
I have also seen this problem in Mozilla Firebird
*** Bug 221572 has been marked as a duplicate of this bug. ***
*** Bug 223334 has been marked as a duplicate of this bug. ***
*** Bug 230523 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.