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

Status: RESOLVED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[jag (Peter Annema)]

From a usability study we've learned that users find it confusing that bookmark
groups open in additional tabs instead of replacing the existing set of tabs.

However, see bug 134800 (dataloss due to closing of tabs).

Ideally we'd do something like make the back button take you back to your
previous set of tabs, failing that we could make this a pref.

Comment 1

[jag (Peter Annema)]

See bug 203961.

Comment 2

[Nicholas Allen]

How is this bug different from bug 158365, bug 159266, or the proposals in bug
159431 ?

Comment 3

[jag (Peter Annema)]

I'll have to read those bugs more closely (I did a quick bugzilla search but
didn't find them, so I filed this new bug), but the main difference seems to be
that if there were 5 tabs and the groupmark has 3 tabs, we close the last two
tabs. Bug 159266 suggests that we keep the last two tabs open.

Comment 4

[Nicholas Allen]

Ah, so you basically want to back the fix in bug 134800 out.  That sounds like
the original behavior implemented before that change.  I think the fix in bug
134800 was based on complaining starting with bug 119599 comment 50 .

Comment 5

[Sander]

bug 153016 has a lot of good comments on this.
As a poweruser I hope the option to append tabgroups will remain in some form or
another (even if it's only drag tabgroup from PT to tabbar), because it saves a
lot of time when you can preemptively start loading a tabgroup without losing
focus on where you are at that point.

Comment 6

[Andy Edmonds]

Changing the behavior of the back button is serious business.  Any chance you
could post some test result info?

Comment 7

[Mark Breitenbach]

I'd like to add my two cents into this discussion if I may. First, I cannot
imagine that opening *additional* tabs would be confusing for users. If you
don't use tabbed browsing, maybe ... but then you're not saving grouptabs in the
first place. As someone who *does* use grouptabs and tabbed browsing
extensively, I cannot imagine *wanting* to replace the existing set of tabs. And
especially closing tabs for you (if the current grouptab has LESS tabs than
what's currently open). 

However, since there are apparently people (based on whatever 'usability study'
is being quoted below (as a side note, I'd *love* to see that one)) ... that
don't like that behavior, perhaps just a preference, or a second menu option
(open in new when Ctrl is held down, open in existing when not, whatever) ...
the flexibility would settle that. 

Personally, I'd like to see opening NEW tabs be the default behavior. It seems
more intuitive to me. 

Regards,
- Geo

Comment 8

[jag (Peter Annema)]

Attachment: l10n change needed

This text will display in the dropdown menu in the back and forward buttons
when the previous/next "page" is a group of tabs.

Comment 9

[(not reading, please use [e-mail] instead)]

Comment on attachment 123516 [details] [diff] [review]
l10n change needed

should this be "Group of Tabs"? or "Group of tabs"?

robinf would know, and would be able to give approval for the l10n change.

if you get r=robinf, you can assume sr/a=sspitzer

Comment 10

[robinf]

I can't approve the L10N change - tha's Bobj's call.

"Group of Tabs" would be correct. No help impact.

Comment 11

[jag (Peter Annema)]

Attachment: "Group of Tabs"

"Group of Tabs" it is then.

Comment 12

[(not reading, please use [e-mail] instead)]

Comment on attachment 123895 [details] [diff] [review]
"Group of Tabs"

sounds like you have r=robinf, and here's my sr=sspitzer

a=sspitzer for 1.4 final,
conditional on bobj's a= for the l10n change.

if he doesn't approve, then please don't land.

Comment 13

[robinf]

Yes, r=robinf. 

Comment 14

[jag (Peter Annema)]

Attachment: Work in progress, patch so far

So this does almost everything we need, except remembering the scroll position
and form fields for each browser's current page. The problem is that the
presShell is gone by the time we try to store these things. I can get the
scroll position to be stored by making persistLayoutHistoryState part of
nsIDocShell and calling that before I remove the browser, but I have no idea
(yet) of how to store form field information "on command".

Comment 15

[jag (Peter Annema)]

Attachment: Patch against pre-branch tree

This should do it. Patch against trunk coming up.

Comment 16

[Sander]

jag: hoping I'm not going to be annoying, but could you explain shortly exactly
what this patch does? Is it what you describe in comment 3?

If so, will there be _any_ way in which the current behaviour of appending a
tabgroup can be retained? confusing as it might be to new users, it's extremely
useful to have a new tabgroup start loading while you're still reading current
tabs, analogous to the case for single tabs with "load in the background" (think
for example of groups of webcomics, which take a while to load, but which you
read in a few seconds).

I think I won't be the only one who'd hate to see the possibility for this go
just before 1.4 with no way to get it amended... Maybe you've already thought of
this and there is a way to retain it, but I fear. I'm definitely not asking for
yet another pref, but some way... drag a groupmark to the PT perhaps, when "load
in background" is set? Yes, a request like that should be a seperate bug, but
there's no way that'd get fixed before 1.4 anymore, while this one seems set to
go in no matter what...

Comment 17

[Jan Varga [:janv]]

Comment on attachment 124378 [details] [diff] [review]
Patch against pre-branch tree

r=varga on XBL/XUL/JS changes
except that XXX and foopy stuff :)

Comment 18

[jag (Peter Annema)]

So here's what this patch does (as of now):

Say you have a number of tabs (or just one tab) open, and you load a bookmark
group. What we'll do is remember the state of your current group of tabs, then
close all of them and open new tabs for the bookmarks in your bookmark group.

If you hit back, we'll take you back to the previous group of tabs (by
remembering and closing the now current group and restoring the previous group).
If from there you hit forward, we'll take you forward to the bookmark group you
loaded (think undo/redo).

You can go back and forward between groups like this until you follow a link or
type a url. Put differently, any page load action will restore you to "normal"
(old, familiar?) back/forward behaviour and forget about the remembered tab group.

Dragging a bookmark group to the tab bar is a different bug. I'll talk to people
about putting the old behaviour on a (hidden) pref, but I can't guarantee anything.


Note to reviewers: I'll fix the XXXjag and "foopy" dead code in my patch.

Comment 19

[Asa Dotzler [:asa]]

I've discussed this with drivers and we're in agreement that this comes too late
to take for 1.4. 

Comment 20

[(not reading, please use [e-mail] instead)]

yes, I agree with asa and the other drivers here.

this really feels like a 1.5 alpha feature to me, not a 1.4 final bug fix.

Comment 21

[Brendan Eich [:brendan]]

Why so much C++ code?

What's the effect of this patch on Firebird?

/be

Comment 22

[jag (Peter Annema)]

> Why so much C++ code?

It's mostly moving code around from layout (PresShell, nsFrameManager) into
nsDocShell and nsContentUtils.

The only "real" change is not keeping a separate nsWeakPtr to the
nsILayoutHistoryState, and synch'ing this with the nsSHEntry later, but instead
setting and getting it directly from the nsSHEntry.

This patch should have no effect on Mozilla Firebird since the
docshell/content/layout changes are (should be!) just moving code around, no
functional changes. All the real work is done in tabbrowser.xml. Note that for
this feature we only need the changes in tabbrowser.xml, navigator.* and
bookmarks.js.

This feature however exposes a bug in the document state savings code in that it
doesn't save state when the document is being torn down. That bug needs to be
fixed if we ever want to do things like drag tabs out into their own window, or
in between windows.

Comment 23

[jag (Peter Annema)]

Attachment: Patch against trunk, also removed XXXjag and foopy

Comment 24

[Johnny Stenback (:jst)]

Comment on attachment 124411 [details] [diff] [review]
Patch against trunk, also removed XXXjag and foopy

- In nsContentUtils.cpp

+static inline PRBool IsAutocompleteOff(nsIDOMElement* aElement)
+{
+  nsAutoString autocomplete;
+  aElement->GetAttribute(NS_LITERAL_STRING("autocomplete"), autocomplete);
+  ToLowerCase(autocomplete);
+  return autocomplete.Equals(NS_LITERAL_STRING("off"));

Wouldn't that be better if you used nsCaseInsensitiveStringComparator() in
stead of callint ToLowerCase() on autocomplete?

- In nsContentUtils::GenerateStateKey()

+  aContent->GetDocument(*getter_AddRefs(doc));
+  nsCOMPtr<nsIHTMLDocument> htmlDocument(do_QueryInterface(doc));
+
+  if (!htmlDocument)
+    return NS_ERROR_FAILURE;

This is wrong, don't throw an error here, just keep going, treat this case as
if there just aren't any forms in the document. I.e. fall through to if
(!generatedUniqueKey) at the end of the method.

+	 formContent->GetDocument(*getter_AddRefs(doc));
+	 nsCOMPtr<nsIHTMLDocument> htmlDoc = do_QueryInterface(doc);

You already have htmlDocument, use it in stead of getting the document from the
content node.

+  return NS_OK;
+}
+
+
+

Go easy on the empty lines between functions here. 2 is IMO enough.

@@ -1410,3 +1626,5 @@
   mScx = nsnull;
   mScriptIsRunning = PR_FALSE;
 }
+
+

No need for these empty lines at the end of the file.

- In nsGenericHTMLElement.cpp>

   //
   // Get the history (don't bother with the key if the history is not there)
   //
-  rv = presShell->GetHistoryState(aHistory);
+  nsCOMPtr<nsISupports> container;
+  doc->GetContainer(getter_AddRefs(container));
+  nsCOMPtr<nsIDocShell> docShell(do_QueryInterface(container));
+  rv = docShell->GetLayoutHistoryState(aHistory);

There's no guarantee that there is a container in the document here, add a null
check.

- In nsDocShell::PersistLayoutHistoryState()

	 if (NS_SUCCEEDED(rv) && shell) {
	     nsCOMPtr<nsILayoutHistoryState> layoutState;
	     rv = shell->CaptureHistoryState(getter_AddRefs(layoutState),
					     PR_TRUE);
-	     if (NS_SUCCEEDED(rv) && layoutState) {
-		 rv = mOSHE->SetLayoutHistoryState(layoutState);
-	     }
+	     //if (NS_SUCCEEDED(rv) && layoutState) {
+	     //    rv = mOSHE->SetLayoutHistoryState(layoutState);
+	     //}

Um, you don't want to call SetLayoutHistoryState on mOSHE any more? If not,
then take out the code in stead of commenting it out.

- In navigator.js:

+  if (index == "back")
+    gBrowser.goBackGroup();
+  else if (index =="forward")

Add a space after '=='.

sr=jst with those changes.

Comment 25

[jag (Peter Annema)]

All those changes made. Since CaptureHistoryState already calls nsDocShell
SetLayoutHistoryState (which calls mOSHE->SetLayoutHistoryState), that call
there is redundant.

Will attach a new patch soon.

Comment 26

[jag (Peter Annema)]

Attachment: Addressed jst's comments [Checked in: comment 29]

Comment 27

[Joe Hewitt (gone)]

Comment on attachment 124430 [details] [diff] [review]
Addressed jst's comments
[Checked in: comment 29]

rs=me

Comment 28

[Adam Lock]

The docshell changes look okay.

Comment 29

[John Keiser (jkeiser)]

Comment on attachment 124430 [details] [diff] [review]
Addressed jst's comments
[Checked in: comment 29]

C++ changes look good to me.

Comment 30

[jag (Peter Annema)]

Okay, checked into the trunk.

Comment 31

[Daniel Bratell]

How do I do if I have a working set of tabs and like to append some more tabs to
those from a bookmark group? It sounds like I will have to manually open single
tabs and load each tab from a single bookmark? Am I correct?

Comment 32

[Andrew Perry]

Since we've been this route before (We've had TABS replace existing tabs before,
just no BACK functionality) ... why would you not make it a requirement to have
a pref to change between APPEND & REPLACE actions?  There was obviously a decent
reason to APPEND in the first place (and my preference now, but I would really
like to see a pref).  

We've been over little things like this before ... Like "Close Tab" taking you
to the right of the left of the current tab ... little nits that, if pref'd out,
would solve all of our problems.

Comment 33

[tyl2]

Replacing existing tabs is the default in Firebird and seems common 
sense to me. Closing existing tabs should not happen and would be 
dataloss. My 2 cents...

Comment 34

[Serge Gautherie (:sgautherie)]

(I read this bug report after reading
<http://www.mozilla.org/status/2003-05-30.html>.)

Let me join the group of supporters who wants to keep a way to APPEND group(s)
of tabs to the tab(s) already opened: see comment 7, comment 16, and others.

Especially, how could I load 2+ groups of tabs at the same time (in the
background, while reading previously loaded pages) ?

Comment 35

[Pascal Chevrel:pascalc (PTO until April 26)]

Questions :

I have several tabs with form data filled in, I open a group of tabs, my pages
are closed but if I click on BACK button, they will reappear ? What happens to
all the data I had filled in forms ?

I have several tabs already opened, these pages are dynamically generated via
parameters sent by forms. I hit BACK, what are the pages that will appear ?
Cached pages or pages with parameters resubmitted ? If this is the latter case,
I can see how we'll have duplicate data recorded in our database from our
intranet forms !!

I am filling in data in a form and need to open a groupmark behind this page to
do cut and paste job from yellow pages, SEC filings or any other business data
available online. How will I do it if I have to cut and paste from three
different pages? Open the groupmark, my current page is closed, I copy the text,
go back to reload my page, paste the data. And I repeat it 3 times ? Do you
intend to drastically improved bacK/forward performance in Mozilla to make it
less painful? Because back/forward performance never was Mozilla's strongest
point...

- I am reading an article and want to open my "weblog groupmark" (about 30
pages) in the background. Does it mean that I'll have to open a second navigator
window to keep on reading ? Thats is: file/new/navigator window + click on
groupmark + click on previous browser window to go back to my reading. Time loss
and one more app in my task bar... hardly an improvement

- I want to create a new groupmark by appending two smaller groupmarks,
something I often do with weblogs. Currently I just click on the two groupmarks
and select "bookmark this group of tabs". How will I do it now ? The only way I
see is to open a second browser window with the second groupmark and drag and
drop all the pages one by one to the first window, which means that something
that required two clicks and a few seconds will become a long and tedious manual
job.

- how will the back/forward of bookmarks appear in history ? If I have to go
back and forward 3 times on a groupmark of 10 tabs, does it mean that there will
be 30 new entries in history ? If this is so, the history feature will become
useless to groupmark aficionados.

- a flash/Quicktime/real... movie, radio, animation is being displayed on a tab,
if I open a groupmark, it will be closed. Worse, I don't imagine that if I click
back, the movie/radio/flash anim will continue where it was interrupted.

Comment 36

[[e-mail]]

I'm a bit reluctant to open a bookmark group now,
I'm worried about my session history getting ignored...

Comment 37

[jag (Peter Annema)]

[e-mail]: closing tabs is okay since (with this implementation) you can
hit the back button to go back to the group of tabs that was replaced,
effectively taking you back to the tabs that were replaced and closed in their
original state (or as close as a normal page back action would take you).

Pascal: going back to a group of tabs should behave the same for each individual
tab as if you typed in a new URI for the tab and then hit back; so, filled out
form fields should still be filled out, plugins will stop playing and be reset
when you hit back, and data shouldn't be resubmitted (instead we either load the
result page from history or give you a warning that you're about to resubmit and
a way out).

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.

I'll see if I can get some time to do both of the above sometime soon; or, if
someone is willing to code up the patches I can see about getting them checked in.

Play with this feature a bit and let me know if you have questions and/or
complaints.

Comment 38

[[e-mail]]

OK, I get it now, if a page loads after loading a group it should turn off group
history. (Although I would still have preferred unclose tabs).

Comment 39

[Brian Mathis]

This really, REALLY needs a pref UI.  I'm not one to normally request prefs, but
this is a MAJOR change that will cause a LOT of people problems.  Given the
voracity of each camp, and the fact that the Tabbed Browsing pref page is rather
sparse anyway, I don't see any reason not to have a radio button to choose
"replace existing tabs" or "append new tabs".

I for one am VERY used to the old way - it has sped up my browsing immensely -
and IMO this new functionality reduces the usefulness of tabs for me by at least
75%.  Not only am I used to it, it also makes much more sense as you don't lose
any data.  I really think that losing data is a major issue here, not a minor one.

The ability to load more tabs in the background while *still using your current
ones* is indispensable.

On the back button issue: yes, you can use the back button to go back to your
previous tabs, but then what's the point of tabs at all?  We've always had the
back button to go back to old pages.  The whole point of tabs is to make it easy
to leave other stuff open so you don't forget about it while you do something
else.  If those old tabs are replaced, what's the point?

And, instead of retyping everything, I 100% agree with everything that was said
in Comment #7.

Comment 40

[johann woeckinger]

i don't want to loose the feature of opening >1 tab-set at once or an additional
tab-set, that's one of mozillas greatest. please give us at least a pref. 

Comment 41

[James Ross]

In my opinion, it would make the most sense to only append the tabs when you
have CTRL held down, just like in the URL bar (opens new tab instead of
replacing current page).

*However*, I REALLY like being able to, at any point while browsing, click my
Webcomics bookmark group, then go read them closing the tabs in turn, without
losing what I'm doing (I tend to check a couple of the comics straight away, but
may leave some open for later).

I'm also a bit dubious about new users - what are they gonna thing when they
suddenly lose all their tabs? Are they going to even /think/ that the back
button might return them to the previous set? I have serious doubts that they'd
have a clue what's going on.

Comment 42

[Rob Stow]

Having your existing tabs replaced when you open a tab group AKA groupmark is a
very annoying bug.  It should be rated "CRITICAL" because it is obviously a
dataloss bug.

Unless the user chooses to set a pref, replacing existing tabs should *never* be
the default behaviour.  The current situation where it has become the default
behaviour is one of the stupidest mutilations that has ever been done to Mozilla.

For Firebird at least, the existing "Open in tabs" option for bookmarks folders
should be replaced with two options:
  "Open in new tabs"
  "Open in tabs - reuse existing tabs"

For Mozilla, the groupmark behaviour should revert back to the old way (ie.,
groupmarks should open in new tabs).  Any idiot who likes to have their existing
tabs trashed when opening a groupmark should be referred to MultiZilla, which
gives them the option of how they want groupmarks to open.

Comment 43

[Eric Lawrence]

The 'forward' feature seems to be broken if the original page is blank. 
Starting with a fresh navigator window, I open a bookmark group, hit Back and
get my old blank page.  But, the Forward button is grayed out.  Back is active,
but there is nothing to go back to.  It also happens if you have multiple blank
tabs open.

(btw, this is with the modern theme on OS X with build 2003060208.) 

Comment 44

[jag (Peter Annema)]

Rob: there shouldn't be any dataloss since you can get back to the replaced
group of tabs.

Eric: I'll look into that.

Comment 45

[Eric Lawrence]

I get this in the JS console after going back to a blank page from a group of
tabs (as in comment 43):

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.gotoIndex]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://global/content/bindings/tabbrowser.xml#tabbrowser.mInstallSH() ::
refresh :: line 20"  data: no]

Comment 46

[Serge Gautherie (:sgautherie)]

Re comment 37: ("sorry" to add to the debate)

> [e-mail]: closing tabs is okay since (with this implementation) you can
> hit the back button to go back to the group of tabs that was replaced,

"No" ! What if I want/need to have both (previous and new/group tabs) data at
the same time to play around tabs ?

> Pascal: going back to a group of tabs should behave the same for each individual
> tab as if you typed in a new URI for the tab and then hit back; so, filled out
> form fields should still be filled out, plugins will stop playing and be reset
> when you hit back, and data shouldn't be resubmitted (instead we either load the
> result page from history or give you a warning that you're about to resubmit and
> a way out).

I'm still one of those who find all this very strange as a default behaviour:
why would I ever want my slow(!) computer to have me waiting for
stopping/starting/resubmitting/etc ?
Remember, even with a "fast" LAN at my company, the Internet access can be very
slow at times due to proxies/etc and lots of people...
And about resubmitting, I surely don't want to add to the load of our web
servers, and have the statistics increase only because of this "bug".

And what of the case where I need to open a groupmark to start giving support to
a calling user: that certainly doesn't mean that I want to have anything else
disappear/forgotten: I usually have to follow links, etc, and when it's over, I
want to be where I was at the start (manually closing the groupmark tabs is just
what I'm used to and what is needed) !
Remember, I usually continue to work in the previous tabs while the groupmark
ones load and then process with my actions !!
And I seldom want to start playing with multiple windows.

But, as there seems to be no turning back yet, let's see:

> We should add one or more ways of loading bookmark groups in the background.

Agreed !!

> Drag & drop of a bookmark group onto the empty space in the tab bar seems good.

Better than nothing, but not good enough: how does one do this with keyboard
only ???
At least pressing Ctrl while selecting (Mouse/Keyboard) the menu item is needed.

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

A pref. for default behaviour seems required !

> I'll see if I can get some time to do both of the above sometime soon; or, if
> someone is willing to code up the patches I can see about getting them checked in.
> 
> Play with this feature a bit and let me know if you have questions and/or
> complaints.

I'd prefer to have your answer on the question (among others) in comment 34 first...

Comment 47

[:aceman]

Yes, leave the possibility to APPEND the new tabs, please. At least as a
preference. The back button feature is very strange.

Comment 48

[Adam Fletcher]

All the comments in support of APPENDing i agree with. IMO, it is dataloss to
replace - i can no longer see the data, and as tab groups are a new UI &
browsing concept for so many people is a bit of shock to see all your tabs go
away. There's no UI convention that the back button should bring tabs back into
existence - if i have 3 tabs open and i load a group with 5 tabs, why should
back remove those 5 and re-create the old 3?

Vote NO on overwrite! YES on append! :)

Comment 49

[Rob Stow]

RE: #44 by "jag"

    "Rob: there shouldn't be any dataloss since you can get 
     back to the replaced group of tabs.

But you can't always get back the data you have entered in forms on the replaced
tabs.  A typical scenario for me is to be posting in a forum, try to use a
groupmark to track down a reference, and then find out I've lost everything I
typed when I try to go back to the forum.

For me the dataloss issue is only the second most important issue.  The major
issue is that when most users have tabs open it is because they *want* them
open.  If they didn't want those tabs open they would have closed them, right ?
 So what they hell does Mozilla think it is doing by trashing tabs that the user
clearly wants open ?    

I had gotten accustomed to reading one tab group while a second loads in the
background, and closing tabs as *I* finish with them.  When I get down to just
two or three tabs left it is time to start the next tabgroup.   Unfortunately,
with Firebird I now have to open a new window for every tab group - and being
forced to use multiple windows kind of ruins the whole point of having a tabbed
browser.

Comment 50

[Brian Mathis]

On dataloss:
The data that is being lost here isn't necessarily the data that's in any forms
or web pages that might be loaded (though it could be) - it's data that the tabs
*themselves* hold.  Specifically, "which pages I'm looking at/want to look at or
working on right now".  That is data in and of itself.

Let's be honest, the mere fact that one uses tabs is because they are lazy, that
is, putting off reading something now and leaving it for later.  If I wanted to
remember all the pages I wanted to read later, I would just do that instead of
using tabs.  Tabs allows the web browser to remember for me so I don't have to.

The current functionality *IS* dataloss specifically because when I look at the
tab bar, some tabs I haven't looked at yet are gone, and I can only get them
back if I remember they were there.  I don't want to do that because I am lazy,
and it's the whole reason I use tabs!

Comment 51

[Daniel Bratell]

> From a usability study we've learned that users find it confusing that 
> bookmark groups open in additional tabs instead of replacing the existing 
> set of tabs.

Is it possible to read that usability study? Maybe it can be interpreted some
other way because the new thing (replacing tabs) doesn't seem to reach optimum
usability either.

Comment 52

[David Crick]

I'm another supporter of KEEPING the original
APPEND behaviour; at the very worst there *must*
be a preference (if only in about:config) to
re-enable it, if we go down this crazy new route.

I'm a fairly long-term Mozilla user (since 0.9.x)
and was miffed when the "load in background" tab
behaviour was changed.

Then we had the recent removal of "Close Other
Tabs", which thankfully has now been added back.

I tried Firebird and was miffed again that opening
a Tabgroup lost my opening page - although now I'm
beginning to wonder if this was now this new method;
certainly I had no inkling that Back may have been
able to be used. (Oh, and Firebird also lacks Close
Other Tabs....)

What amazes me is from the wording of the original
messages that this was all (and could still be!) full
steam ahead get-it-into-the-final-release, when we've
suddenly got a change in UI for the first time in
however many releases. It's "close other tabs" all
over again....

The new weird behaviour plus the inability to close
other tabs (as well as other irritations) are two major
reasons I'm not using Firebird right now. I had hoped
to be able to stick with Mozilla [Suite] but this last
minute change just prior to the final release leaves
me stunned.

Back to Lynx, I guess....

Comment 53

[Serge Gautherie (:sgautherie)]

Yet another example of wanting to have tabs remain:

Every morning, when starting Mozilla, I open a group of webmail tabs;
I sure want thoses tabs to stay there the whole day, whatever else I do in the
meantime (including opening other groupmarks).

Note that, for theses sites, a server session is maintained: if I loose the tabs
at any point, I loose the ability to close the session (security issue) too.

This case(s) also applies to all "private sites", including banking, B2B
activities, etc !!

Comment 54

[Pascal Chevrel:pascalc (PTO until April 26)]

I've been using this new feature for a few days to give it a chance. Sorry but
my surfing is now more painful than it was before. The time needed to open a
groupmark and afterwards coming back to my previous tabs can reach up to 20
seconds when it was 0 second before. My main groupmark has 37 tabs, clicking the
back button means that each individual tab (with a very irritating blinking
effect) is being closed in front of me and then all the previous tabs are
opened. This is a big big speed regression for tab users. It is clear to me that
the usability study was done on people who never used tabbed browsing and still
think one browser per page.

I also had problems twice with the back button being disables after visiting
hotmail.com.

Third ploblem, this new browsing behaviour is producing memory leaks. Open a
page, click on a groupmark, then click on back/forward with the task manager
open and on each back/forward operation, you see memory use rising of about 100
kb. With the previous appending method it didn't happen since you didn't have to
go back and forth (not saying that the memory leak bug is caused by this new
replace method, it probabky just emphasizes a current memory leak on
"back/forward" or "close tab").

Comment 55

[David Crick]

This is horribly, horribly wrong.


Firstly - the nightly I've tried is a 1.5a, which is exactly where
(i.e. in *alpha*) this new idea should go. Irrespective of the bad
points I'm about to mention, if this "feature" is in 1.4 [Final],
then it should be PULLED from there *immediately* - this is too
much of a change for a final (and indeed, final Mozilla Suite)
version, even aside from the terrible new behaviour it introduces.

(BTW, does ANY other tabbed browser do things differently to how
Mozilla did, or are the Mozilla crowd just going off on a magical
UI mystery tour of their own here?)


Two of my biggest gripes come from both VISUAL and "DATA" loss of
information:

1. When the tabs are replaced, the old ones just disappear
   completely, and it's not until all the new tabs are loaded that
   the Back button becomes active and the drop-down for it reads
   "Group of Tabs".
   
   If you're not paying attention then VISUALLY YOUR TABS ARE GONE.
   
2. Once in this new group, as soon as you follow a link then the
   back button option to the old group is removed. i.e.,
   
   your old tabs REALLY ARE GONE, and you ain't getting 'em back.

Point 2. alone is enough to convince me that this is a Bad Thing,
and that this new feature should be optional/experimental and that
the old behaviour should be the default and correct one.


When I have to use a Windows machine with Internet Explorer, I find
myself "Open Link in New Window" all the time, but the screen soon
becomes cluttered and within about 4 or 5 new windows I've given up.

This is particularly prevalent when I'm using a search engine: start
opening links to pages returned as I'm scrolling down the results
page, waiting for them to load in the background as I keep reading
the results. I'll then say go and read the first (typically 10) set
of pages while I click on "Next" to pull the next set of results.

With Mozilla this was a perfect use of Tabs: load each search result
into a new tab - easily 10 (which becomes impossible if you have to
open a new window as in IE), look through those, CLOSING irrelevant
tabs and LEAVING useful tabs open. Maybe I'll open some more tabs
from the next set of search results too, and eliminate most of them.

I'll also be following links WITHIN the pages I've opened, also
using new tabs to explore areas within those sites.

The end result is the search engine in the first tab, then perhaps
4 or 5 useful pages left open in the remaining tabs.

Very typical and very useful, and completely undoable with the new
behaviour.


As others have also stated, loading sets of tabs in the background
for *future* reading, or keeping a set of tabs *always available*
are also typical browsing behaviours.


I think I back comments that the new method is "new window" type
behaviour, and possibly stems from users who simply *don't*
understand Tabs. As an additional or optional behaviour, sure, add
it in, but it MUSTN'T be the default or indeed only behaviour,
ESPECIALLY in 1.4.


To reiterate:

1. the new behaviour is confusing visually
2. the new behaviour LOSES previously opened sets of pages
3. the new behaviour prevents existing usage techniques

Comment 56

[Serge Gautherie (:sgautherie)]

When will we have the feedback from the users who were studied ?

Wouldn't they be happier a (pref) behaviour like "open groupmarks in new window" ?

Comment 57

[Eric Lawrence]

> if this "feature" is in 1.4 [Final],
> then it should be PULLED from there *immediately* - this is too

Read comment 19 and comment 20, this isn't going into final.

> (BTW, does ANY other tabbed browser do things differently to how
> Mozilla did

Safari implements their bookmark groups this [new] way.

(not trying to fan any flames, just providing information...)

Comment 58

[David Crick]

Eric, re your comment 57, I appreciate the info.

I'm glad this isn't going into 1.4 Final, but I
still think it's hideous - though that has nothing
to do with Safari supporting it :)

Comment 59

[Pascal Chevrel:pascalc (PTO until April 26)]

DATALOSS WITH XUL APPLICATIONS ! :

1 go to http://www.cfmentor.com/~faser/mab/
2 launch the Amazon browser by clicking "open in window"
3 search data
4 open a groupmark
5 click on Back to come back to the Xul application

All data disappeared

Comment 60

[Jason Bassford]

I can't believe I missed this bug, since I follow almost every tabbed browser
behaviour bug.   (What's also suprising is that it wasn't linked in any way to
any of the other tab group bugs I've filed and/or already follow.)

Marking some dependencies.

Comment 61

[Bob Rusbasan]

I know this is a matter of opinion, but I thought it was a HUGE step forward
when they changed it to append instead of replace, and I really find it hard to
believe that very many people disagree.  I have my doubts about this usability
study.  Perhaps they didn't take into account that sometimes advanced features
take a little getting used to.  I'd hate to see a major negative change like
this made permanent because some unknown group of users had a little bit of
initial confusion (but very well may have liked it better the way it is, given a
little time using it).

There are very few here saying they'd prefer replace to append.  Additionally, I
notice that those that do seem to be speaking more in the theoretical sense
while those preferring appending seem to be speaking from their own experience.

I also hate the change in functionality to the Back button.  How can you just go
back on a single page if you've just loaded new tabs and then loaded a new page
in one?  If you hit Back in that page, do you get your old tabs back?  Do you
have to hit back until you've restored that one tab to the first page loaded
with the new tabs and then hit Back again to get the old tabs?  What if you're
looking at a different tab, then what, will one Back restore all the old tabs? 
It is combining single-page behavior with all-tabs behavior into one control
(the Back button).  Tell me THAT is not confusing!  Has anybody usability tested
THAT?  I highly doubt people will find that not confusing!

So this is one more vote for this being a big, big mistake, especially given
that in Firebird they are eliminating scores of options to keep things simple. 
If you're going to force people to do it one way, then it should append.  They
can easily figure out to close the extra tabs that way.  With replacing, it will
be very confusing when all their stuff disappeared, and the Back button will not
be intuitive.

Bottom line:  One way is consistent and uses simple user-interface metaphors
(extra tabs are added, Back works on a single page).  The other way may avoid
some extra tabs that some users might not expect (until they get used to it) but
makes a complete mess of things (rules for the Back button that few people will
be able to understand).  Just horrible.

Comment 62

[Jason Bassford]

> There are very few here saying they'd prefer replace to append

Only the people who object to something are the most vocal.  Believe me, there
are a lot of people who prefer replace who just haven't commented (and who *do*
prefer it from experience).  Thankfully, they haven't really chimed in yet
because that would drag this bug down to nothing more than an unproductive, and
largely off-topic, debate.

> this is one more vote for this being a big, big mistake

This bug, as far as I know, is *still* about making the behaviour conditional. 
(The summary stills says so.)  If so, this is an interim step to a solution in
which both sides of the coin are happy.  Depending on how you look at it, things
just have to get worse before they get better again.  This is exactly what
happened with the recent process of getting new tabs and new windows separated
from what happens when Navigator is started (bug 109551 and bug 107671) - things
were changed from one "camp's" preference to another, and there were a lot of
complaints from the, then, unhappy side of things - but the process worked
itself out until both were satisifed when it became a preference rather than
something hardcoded.

In my mind, it's just delaying things, and causing uneccessary noise, to be
making any comment to this bug at all in terms of whether it should be replace
or append.  The bug is still open, so things are not yet finished, and the
module owner is already more than aware of the issues involved.  (In fact, a
flood of negative comments will likely cause him to get fed up and keep things
as they are just to be rid of it all.)

Constructive comments here should be on technical methods of how to make the
behaviour conditional, and how to address actual bugs in the current
implementation.  (Not just everybody saying that they don't like it.)

Comment 63

[Jason Bassford]

Correction: That should have been bug 109551 and bug 197671.  Apologies for the
SPAM.

Comment 64

[Pascal Chevrel:pascalc (PTO until April 26)]

More dataloss bug introduced by the new behaviour :
1 click on groupmark
2 pages load
3 click on Back
4 click on forward

Most of the tabs are blanked because they had not finished loading all their
elements at first load althouh they were perfectly readable at first load.

Second dataloss :
1 have a page displayed
2 click on a groupmark
3 click on a second groupmark
4 click on back

result : you can't come back to the first page

Third dataloss :
1 debug a page with the DOM inspector
2 click on groupmark
-> all the debugging work you did setting styles and cutting nodes is lost

fourth dataloss :
1 go to a page using DHTML for content or editing like
http://demo.bitfluxeditor.org/
2 click on groupmark then back
3 everything is reset, your work/data/position is lost

fifth dataloss, frames :
1 go to http://www.emule-project.net/
2 click on FAQ
3 click on beginner's guide
4 click on groupmark
5 once groupmark is loaded, click back
6 once you're back to the framed page, click forward to go back to the groupmark

-> forward is greyed out.

Tabbed Browsing has been very painful this week with this new feature, I haven't
yet found a single advantage but the list of inconvenient is steadily growing :

- can't use XUL Amazon browser, XUL games or any of these new XUL apps in tabs
anymore
- going back and forward can take up to 30 seconds with my screen blinking
frenetically by the closing/opening of dozens of tabs
- frequent loss of my previously opened tabs
- loss of all the flash/quicktime/real... downloading which means, specifically
that I can no longer have a streaming radio playing in a tab or a quicktime
trailer from apple.com downloading in the background
- database retrieval (like bugzilla requests) that need time are stopped by the
opening of groupmarks
- can't use DOM inspector with tabs
- works randomly from pages with frames
- copy/paste from background tabs now takes ages with the new behaviour (PITA to
quote other people from Blogger)
- merging groupmarks is now impossible from the UI

This is a major dataloss bug and I don't even talk about performance, up to 30
seconds just to go back and forward (when i didn't even need to before) with CPU
climbing to 100%.

Comment 65

[Bob Rusbasan]

Jason, you say that since this is "conditional" (ie, a preference) then I'm
basically complaining about nothing.  I would certainly agree if I were not
99.99% sure that when I first looked at this it did NOT say it was conditional.
 If you look at the boatload of comments from BOTH sides early on, it sure seems
EVERYONE was going under the impression that this would just be how it worked,
period.  If you try out Firebird and see how they've slashed and burned tons of
options in an effort to streamline things, it gets pretty scary.

Also, look at the 1.4 RC1 status update
(http://www.mozilla.org/status/2003-05-30.html) and you'll see this:

"Opening a bookmark group now replaces the existing tabs, rather than appending.
You can use the Back button to revert to your previous set of tabs (bug 203960)."

That is how most people found this bug.  The status update for RC1 of 1.4
flat-out says it "now" does this "rather than appending".  Does that sound like
it's optional?  It doesn't to me.  If that is not true, then someone should
update that page.

If it is a preference, then I personally couldn't care less whether they do it
or not.  If they don't take away my append tab browsing behavior, then I really
don't care what alternatives they offer to people who want to do it differently.

Can we get a clear statement on what the plan is?  Is replacement to be
1.  The only way it works,
2.  A visible option (in the Preferences) dialog, or
3.  A hidden option (in about:config)?

Also, if #2, then which will be the default?

Please, Mozilla team, shut us all up by letting us know what the plan is.  If
this is going to be just an option then I'm sure virtually all posts will stop.

Comment 66

[Brendan Eich [:brendan]]

Pay attention, please and stop spamming this bug: this change landed only in the
1.5alpha trunk.  The status update item on 1.4 RC1 is completely separate from
the later, independent item about the 1.5alpha trunk change todo with bookmark
groups.

/be

Comment 67

[Serge Gautherie (:sgautherie)]

Re comment 62:

I like your post.

As one of the objecters, my (perhaps wrong) understanding had been that the
feature was included as is in v1.5a nightlies, and I guessed that this meant
that it was intended to stay as is (at least for all v1.5x).
May be I missed the relevent comment about this "step in the process" status :-(

I would have expected this temporary coding to be tested as a patch only by a
few volunteers: but I must have been wrong there too.

Then, my last suggestion, after which I'll let you work further on this bug:
if v1.5a milestone was to be released as is, please add a release note.


PS, since there was a mid-air collision during my post:
About comment 65,
I agree with comment 66: v1.4rc1 should be replaced in the former comment by
"2003.05.30 status update (applying to v1.5a)";
that said, what is written in comment 65 is just how I came to this bug, and
what I am still wondering about.

(end of spam, I hope)

Comment 68

[Bob Rusbasan]

Brandon, I paid attention to the official status page, which said this was in
1.4 RC1.  On this bug page there are some vague comments like "this is too late
for 1.4".  Since those come after many complaints and requests for changes, it's
not clear what exactly is too late for 1.4 (the original change or the proposed
modifications of the change).

Believe it or not, we're trying to help.  I don't think comments about how we're
"spamming" are productive.  Trust me, if people didn't "spam" and this was just
put in as originally planned then the amount of complaints you would have
received would have dwarfed what you see here.

If you guys wish to avoid "spam", why not take just a tiny bit more time and
drop in a clear status update?  In this case if someone had posted, "No change
will be made to the current behavior in 1.4, and this will be added as an option
in 1.5", then it would have been a dead issue (assuming that IS the plan; it's
still not entirely clear to me).  That probably would have taken less time than
railing against "spammers" and telling people to "pay attention".

I'm also not sure why you call this a "separate issue" from the 1.4 RC1 change.
 The description of that change linked to this bug, so apparently somebody
thought it was the same issue...

Comment 69

[Brendan Eich [:brendan]]

You can't even spell my name correctly, and you misread the status update. 
Please stop adding noise here.  That goes for the rest of you noise-makers.

/be

Comment 70

[Bob Rusbasan]

Brendan,

I apologize for misspelling your name.

If I misread something (which I don't believe I did), then I was not alone. 
Rather than assume all the above people are at fault, perhaps the Mozilla team
should consider that with a little better communication they could save
everyone, including themselves, a bit of time.  Calling them "spammers" and
"noisemakers" isn't productive (and it amazes me you'd say that to some of your
most dedicated users during a pledge drive).  Again, everyone here is trying to
help.

Bob

Comment 71

[timeless]

<offtopic>
well there's another case of misreading

mozilla.org is not an organization / nonprofit under us law, nor does it have a
pledge drive.

mozdev.org otoh is sort of an organization, is trying to list itself as a
nonprofit and is in need of funds (because it doesn't get money from Netscape
unlike mozilla.org).

Please don't respond publicly to this point.

Comment 72

[Brian Mathis]

Is the "conditional" part of this ever going to be implemented?  I'm getting the
feeling that was never the intention.

This *major* change in behavior is still causing me and I'm sure many others
problems, but I figured "OK, this is going to be conditional, so any time now I
should see a pref or something for it".  Well, it's been over a month since it
landed, and nothing.

Yes, some things take time.  But this being such a huge change, one would expect
the "conditionality" part of it to be a high priority.  What's the deal here?

Comment 73

[Adam D. Moss]

<qa_ignore>
In MozillaFirebird bookmark groups do replace instead of append (though I don't
know about the 'conditional'.  (IMO it's really annoying actually, but there ya go!)
</qa_ignore>

Comment 74

[Hermann Schwab]

Make bookmark groups conditionally replace existing tabs instead of appending,
is the title of this bug.

This fix lacks the 'conditionally', and therefore created 6 dataloss bugs with
the new behaviour, bug 209290 through 212122 in the 'blocks' table above.
Before this fix, you could load multiple groups, now you can load only one and
have to add additional links each one separately.
If you wanted the groupmark to replace the previous contents, you only needed
two additional actions: Close Other Tabs, Load Groupmark, Close first tab.
Maybe that had been confusing, but it is more confusing having lots of
groupmarks, and not beeing able to combine them.

Comment 75

[Asa Dotzler [:asa]]

not gonna happen for 1.4.1. mozilla1.5a released so unsetting blocking request.
nominating for 1.5b

Comment 76

[Gert-Jan Vons]

Another issue related to the changed behavior: the idea of using the back button
to move back to the previous group conflicts with the use of the back button to
move back to the previous page (see bug 214905).
(It is actually mentioned in some of the comments here but I missed those while
glancing through the thread the first time)

If the usability study showed people find it confusing that the groups open in
additional tabs instead of replacing the existing set, why not offer the
possibility of opening the group in a new window for example?
That way, the new group is clearly separated from whatever tabs the user may
have open in the existing window; no data is lost, and going back to the
previous set of tabs is very easy.

Maybe some users find this new behavior less confusing, but will they understand
the notion of groupmark history in addition to (and currently merged with) page
history?

My personal feeling concerning this change: I find it both disturbing and
annoying, but if some users want it why not. However, under the condition that
it there's some kind of preference setting for this. Right now I prefer the old
behavior, and I'm wondering whether I should put up with it or just go back to
1.4 where this works ok...

Comment 77

[Hermann Schwab]

There are 10 bugs in the 'Blocking' list, partly causing data loss,
caused by the new behaviour.
If the 'Enhancement' would have been implemented conditionally, these bugs only
would have to be taken by people preferring the new behaviour.
I´m missing one of the most powerful features of Tabbed Browsing, loading groups
additionally.
Please fix the bug according to the Summary line, 

make the new behaviour 'conditionally'

Comment 78

[Eliot Lear]

With regards to comment 77, might one consider it a bit of an abuse of the bug
system and just a bit disengenuous to have filed 10 bugs over the same behavior
when one would have sufficed?

Comment 79

[Jason Bassford]

> filed 10 bugs over the same behavior when one would have sufficed?

The behaviour isn't the same.  Each dependent bug is about a clearly different
specific problem.  The fact that fixing this one will fix those doesn't preclude
the possibility of fixing one of them without fixing the rest.

Comment 80

[Greg]

Please make this new behaviour of closing existing tabs an option

Comment 81

[Jack Eidsness]

This is kind of ridiculous, I have never seen code written deliberately in favor
of data loss before.  The irreversible closing of tabs was such a problem that
we just had to add a warning when closing a window, but now you can do the same
damage by opening a bookmark?   If for no other reason, its easy to see that
people who feel they have too many tabs open have already had a way out - just
close the tabs you dont want.  I can't even use a bookmark group now because I
never have less than 10 tabs open and I am rarely aware of what i was doing in
all 10 tabs (i have an invention called a "computer" to track that stuff for
me).  This bug fix decision is completely opposite to the philosophy of someone
who wants a tabbed browser.

Having too many options (tabs) available may be confusing, but it has a very
simple way of getting un-confused.  No one is going to bookmark a bunch of tabs
when they don't even know what a tab is or where to find their mysterious 3
bookmark tabs that they just opened.  There is no undo for closing out an
arbitrary large number of tabs.

I am using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5b) Gecko/20030827,
just lost a ton of tabs and it was EXTREMELY confusing.

Also I will suggest that if you don't want to add a new option for this in the
preferences (it is terribly obscure), hook it into the "load links in the
background" option.  Anyone who likes to load links in the background probably
also likes for his bookmarks to add tabs rather than subtract.

Please forgive me, I can't read all of this, I'm at work and need to figure out
what I've been doing for the past hour before opening a bookmark closed out a
bunch of my tools.

Comment 82

[Prognathous]

Where can we get hold of this "usability study"? many of the commenters here,
myself included, would like to read it, as its verdict does seem to contradict
common logic (by inducing data-loss that is).

Prog.

Comment 83

[Patrick]

[e-mail] please do NOT remove flags set by the drivers. 

Resetting the minus flag as set by Asa on 2003-08-29 10:32:28.

Comment 84

[Derek Ross]

The problem with the new tab behavior is that it discards the metaphor that
underlies the process of tabbed browsing.

IMHO, tabbed browsing is functionally identical to the act of opening pages in
new windows.  In fact, in the bad old days before TB, I would always open pages
in new windows then minimize that window and let it load in the background.  The
advent of tabs allowed me to do the same thing, while reducing the clutter of
apps on my Windows taskbar.

If you extending the metaphor to group tabs, it's easy to equate the opening of
a groupmark to be the same as opening a list of URLs in new windows.  Also,
because new windows didn't have active "back" buttons, there was no reason for
tabs to.

The reason I'm pointing this out is that there may be a better way to reduce
novice confusion without revamping the whole tabbed browsing scheme.  Perhaps
users are confused because they don't understand that TB is supposed to be an
alternative to opening links as new windows, an alternative that is functionally
identical, yet is different in appearance.

My proposal is that we could provide the option that produces a visual tabbed
browsing interface that is self explanatory to novices.  

To be specific, the tabs should be moved from the top of the browser to the
bottom part.  Also, the tabs should be visually changed from the
manilla-folder-like tabs, into buttons similar in appearance to the ones you
would see on the Windows taskbar.

With the tabs being adjacent to, and visually similar to, the Windows taskbar,
it would be much easier for novices to develop a intuition as to what's going on
during tabbed browsing.

(Of course, it would be preferable for interface option to be a pref.)

--Derek Ross

Comment 85

[Jason Bassford]

> tabs should be moved from the top of the browser to the bottom part.

That suggestion has nothing to do with this bug.  See bug 104566.

> IMHO, tabbed browsing is functionally identical to the act of
> opening pages in new windows.

Yes, others have differing opinions.  Hence the summary of this bug being for
"conditionally" replacing tabs.  That's already been establishd.  (The need for
this to be conditional.)

Everybody: Either submit a patch or wait for somebody else to do so - we all
know the issues here, there's no reason to simply repeat them all over again.

As a more on-topic comment, could an approach to this problem be to simply port
the Firebird preference "browser.tabs.loadFolderAndReplace" which doesn't exist
in Mozilla?  (The default setting and/or existence of preference UI could be
discussed later.)

Comment 86

[Eliot Lear]

One of the things I am concerned about is that the coupling between the "Home"
button and bookmarks may in this case be too tight.  You may want one behavior
for a bookmark and another when you click on the "home" button, especially with
regard to tabs.

What do other people think?

Comment 87

[Jason Bassford]

> You may want one behavior for a bookmark and another when you click
> on the "home" button

That's not this bug.  (Which should be about tab groups in general, not the home
group edge case.)  Some possibilities: bug 184660, bug 184707, bug 188329. If
you want a home tab group to behave differently than a normal tab group, and one
of those doesn't cover it, you should file a new bug.

Comment 88

[Daniel Bratell]

I've tried to look at the patch that added the replace behaviour but couldn't
find an obvious place where that decision is made. jag, could you give me a
hint? I would really like to find a way to fix this.

Comment 89

[Peter Lairo]

Could someone please mention the comment# where the "conditions" are listed /
explained in the status whiteboard for easier orientation in this monster-bug?

Comment 90

[Jack Eidsness]

I would like to apologize for the tone of my previous message - it was totally
inappropriate.
  If the patch in this bug is the one that added the feature on the back button
to go to the previous group of tabs, it is not working for me. I'm using
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5b) Gecko/20030827
  When clicking the groupmark, the back button lights up (if it was gray before,
or stays lit if it was), and while they tabs are loading in the background, if I
click the back menu attached to the back button, it appears empty (it is a tiny
square of textless menu).  If they ever all finish loading, the back menu will
no longer be empty, otherwise I have no option to go back to the previous group
of tabs.  As soon as I click a link, switch tabs, etc. the back button will go
gray again (and subsequently light up without the previous group of tabs, if I
went to a new page).  It seems  to be the exception rather than the rule to have
 a 'back to previous Group of Tabs' option available.
  I have only found one situation where I can get the back button to go to a 
previous group of tabs, and that is when I stay on the focused tab and click
nothing until all tabs are loaded (when one of them is this bug, thats a long time).

Naturally, I would still prefer appending tabs rather than replacing. 
Regardless of that opinion, If the back button's new feature doesn't find a way
to show up sooner and go away later, I would recommend rolling back to the
previous behavior (appending tabs) because it doesn't make sense to try and use
the replace behavior without having a dependable way to go back.

Comment 91

[Greg]

If anyone wants to try a temporary way to stop tabs being closed when opening a
bookmark group, extract chrome/toolkit.jar  (with jar or winzip)

Edit xpfe/global/resources/content/bindings/tabbrowser.xml
and change the line
          var oldCount = this.mPanelContainer.childNodes.length;
To
          var oldCount = 0;

Then pack it up into the jar file again.

Obviously this is not a full solution and may cause other problems, but it works
for me.

Comment 92

[Rick Stockton]

I HATE this change. It appears than the change was proposed as "conditional",
but no GUI-accessable pref is visible in 1.5b. 

Comment 93

[David Crick]

re comment 91 - Greg, many thanks for this work-around.

I am now able to productively use (and, *test*) post-1.4
Moz suite builds.

Comment 94

[Peter Lairo]

This bug seems silly. The default should be to replace ALL tabs (just like when
one opens one bookmark, it REPLACES the current page). A modifyer (CTRL?) should
be used to append to the existing tabs (as this is a poweruser behavior), IMO.

Suggest WONTFIX (and to restore the "replace" behavior).

File new bug on Modifier-to-append behavior? (KISS)

Comment 95

[Jason Bassford]

> Suggest WONTFIX (and to restore the "replace" behavior).

The original/previous behaviour was append, not replace.  It was replace that
this bug introduced on May 29th.  Resolving this as WONTFIX would likely involve
backing out the patch that's already been applied.

If the "conditional" part of this bug is to be dropped, then the module owner
would have to change the Summary and resolve the bug as FIXED without it.  But I
don't think (or hope) that will happen.

Comment 96

[John L. Villalovos]

Okay.  I have to chime in.  The current behavior in Mozilla 1.5beta SUCKS!!!  I
hate this replace feature with a passion!  Append was so much nicer for me.  I
do NOT want to lose all my currently open tabs because I click a bookmark of tabs.

Also as currently implemented this feature does not work for my style of
browsing.  I click my bookmark of tabs.  I then go through them opening new tabs
and closing them.  By the end of it I can't go back anymore on the last tab
remaining and so I lose access to everything I had already open :(

Please change back to the append behavior.  Or at least get an option in the UI
to set it.

Comment 97

[Vaclav Dvorak]

Please forgive me for adding to the spam, but could someone tell me what is the
status of this? Is this waiting for some decision, or is this waiting for
someone to contribute a patch? What kind of a patch would have a chance of being
accepted? There's a little bit too many comments to read. And while you're at
it, you could add the info to the Status Whiteboard for the benefit of others
(or I'll do it then). Thanks.

For the record, I too hate the new behaviour of replacing all existing tabs. I'd
prefer to replace the current tab and add the other tabs in the group as new
tabs (I don't really care about where exactly they should be added). The
previous behaviour of just adding all of the tabs as new was fine with me, too.

Comment 98

[Jason Bassford]

This bug is waiting for a patch, or some kind of technical discussion.  The SPAM
isn't helping in any way (almost everything being said has already been said and
"Me too!" comments add nothing towards a solution)...

I see two technical solutions that could be accepted.

1. Implicit behaviour modification, along the lines of replace all tabs if
regular click, append tabs if <ctl>-click.  (As with single tabs.)  That
solution would have to take into account the bookmarks that appear from the
Bookmarks menu in some fashion which, currenly, ONLY allow for a regular
left-click.  (Adding the ability to right-click such an entry, for example, is
covered elsewhere.)

2. Set a permanent behaviour via a preference, either hidden or exposed in UI. 
The first step here would be to hook the preference up, then deal with the UI
separately as a separate bug.  As I mentioned in comment 85, this should likely
be a simple port of the Firebird preference "browser.tabs.loadFolderAndReplace".

Comment 99

[jag (Peter Annema)]

Attachment: Add pref and code for append vs replace

Comment 100

[jag (Peter Annema)]

After talking to Neil, we came up with this text:

When opening a bookmark group

( ) Add tabs
(o) Replace existing tabs

Patch coming up.

Comment 101

[jag (Peter Annema)]

Attachment: New text, removed redundant check on selected tab [Checked in: comment 107]

Comment 102

[[e-mail]]

Comment on attachment 131899 [details] [diff] [review]
Add pref and code for append vs replace

>+    if (!pref.getBoolPref("browser.tabs.loadInBackground") &&
>+        gBrowser.selectedTab != tab)
>+      gBrowser.selectedTab = tab;

>+      if (!PREF.getBoolPref("browser.tabs.loadInBackground") &&
>+          browser.selectedTab != tab)
>+        browser.selectedTab = tab;
browser.selectedTab setter calls tabbox.selectedTab calls tabs.selectedItem
which tests for val.selected, so strictly speaking you don't need to check
yourself.

>+<!ENTITY loadGroup.label "When opening a group of tabs">
The help calls it a bookmark group or a groupmark - group of tabs seems to
refer to your currently open tabs.

>+<!ENTITY loadGroupAppend.label "Append">
Add new tabs, perhaps?

Comment 103

[[e-mail]]

Comment on attachment 131900 [details] [diff] [review]
New text, removed redundant check on selected tab
[Checked in: comment 107]

Hmm... my bugmail isn't coming through reliably, I haven't seen the review
request for this.

Comment 104

[Peter Lairo]

> ( ) Add tabs
> (o) Replace existing tabs

That looks like a good solution. Curious: what were the reasons for not going
the "modifier" route? That would allow both behaviors AND save a pref.

Comment 105

[Jason Bassford]

See comment 98.  There is currently no way of using a modifier on a bookmark
link from the regular bookmark menu.  Yes, it could be done - but it would take
more time to implement.  Personally, I'd rather resolve this as soon as
possible.  Another bug for a modifier can always be opened after this one.  The
preference solution is the easiest and fastest to implement at the moment...

Comment 106

[jag (Peter Annema)]

I'd like to add modifiers later, it's just a more intrusive change and from what
I understand drivers wanted a non-intrusive fix for 1.5.

Comment 107

[Asa Dotzler [:asa]]

Comment on attachment 131900 [details] [diff] [review]
New text, removed redundant check on selected tab
[Checked in: comment 107]

a=asa (on behalf of drivers) for checkin to the Mozilla 1.5 branch. Please add
the fixed1.5 keyword when this is landed on the branch. Thanks.

Comment 108

[jag (Peter Annema)]

Checked in.

Comment 109

[Jason Bassford]

Verified in 9/23-04 Win32 build.

Comment 110

[Alfonso Martinez]

*** Bug 216049 has been marked as a duplicate of this bug. ***

Comment 111

[HJ]

Both reviewers missed this bug:

http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/bindings/tabbrowser.xml#1213
+            tab = tabs.firstChild;

What |tabs| are you referring to at this spot? I guess you need
|this.mTabContainer| instead of tabs here.

Comment 112

[Brendan Eich [:brendan]]

Someone come up with a patch for 1.6b, quickly -- thanks (and thanks to HJ for
finding the flaw that got checked in).

/be

Comment 113

[Serge Gautherie (:sgautherie)]

Re comment 112:

I'll post a patch based on comment 111, in minutes ... Stay tuned.

Comment 114

[Serge Gautherie (:sgautherie)]

Attachment: Comment 111 patch v1: <tabbrowser.xml>, 1 'tabs -> this.mTabContainer' [Checked in: comment 118]

Comment 115

[Serge Gautherie (:sgautherie)]

Comment on attachment 136496 [details] [diff] [review]
Comment 111 patch v1: <tabbrowser.xml>, 1 'tabs -> this.mTabContainer'
[Checked in: comment 118]


'blocking1.6b+' patch.

Comment 116

[[e-mail]]

The error probably wasn't noticed because SeaMonkey doesn't actually use the
return value from the else clause in a useful way.

Comment 117

[Brendan Eich [:brendan]]

Comment on attachment 136496 [details] [diff] [review]
Comment 111 patch v1: <tabbrowser.xml>, 1 'tabs -> this.mTabContainer'
[Checked in: comment 118]

neil: and the exception was caught and ignored?  Just checking.

/be

Comment 118

[[e-mail]]

Supplementary patch checked in.

Brendan, the operation would not visually fail despite logging an exception.

Comment 119

[Prognathous]

Anyone who doesn't feel that this bug stands on solid research, may be
interested in Bug 243740 which requests to provide the aforementioned usability
studies for public evaluation.

Prog.

Comment 120

[nick]

Why on earth would anyone want to replace the tabs by default with no way of
changing that behavior? This HAS TO at least be a preference. It's completely
stupid to replace the existing tabs. 

1. It defeats the whole purpose of tabbed browsing 

2. It's very easy to close the tabs you don't want open manually. 

3. The potential for data loss remains.

Tabbed browsing is the main reason I switched to Mozilla from IE and the remains
the main reason I give for others to switch. This replacing tabs business is
very frustrating for me... and obviously others as well.

Comment 121

[beryan]

I don't care about 'do not comment'. Take some feedback.
This behaviour is broken. Don't nuke people's tab content. If you lose sleep
over having extra tabs you don't want:

1) Close them first. Like all good housekeepers. CTRL-F4 on Windows.
2) Close the parent window and open a new one.
3) Open another window and work in there.

Don't force b0rkenness upon everyone.

Comment 122

[moz]

Don't make dissaplear the tabs of the people!  This is evil!

> This HAS TO be a preference (at least).

Comment 123

[tech]

I don't understand : when has this behaviour has been changed ? has it really been changed ? 
My browser still work as before and the bug opening date is 2003-04-30

Comment 124

[Hermann Schwab]

(In reply to comment #122)
> Don't make dissaplear the tabs of the people!  This is evil!
> > This HAS TO be a preference (at least).

That's the way Firefox is made, you are a bit late.
Install some TAB extensions, or use about:config to set browser.tabs.loadFolderAndReplace to FALSE

This bug was fixed way before Firefox 1.0, you've got the preferences via about:config in Firefox 1.0 


(In reply to comment #123)
> I don't understand : when has this behaviour has been changed ? has it really
> been changed ? 
> My browser still work as before and the bug opening date is 2003-04-30

No, this bug didn't change after Firefox 1.0 was released.

Keywords: fixed1.5 is misleading, 
as it refers to Mozilla(Suite)1.5, not Firefox1.5

This bug implemented the default behaviour of Firefox.

This bug is about opening a group of tabs. 

Behaviour before this bug was to append the group of tabs to the existing tabs, so if you had two tabs open and added a group of 4, you got 6 tabs open. Open another group of three tabs, and you had 9 tabs open.

After the check-in in Comment #30  2003-05-29 17:21 PDT this behaviour was gone, bookmark groups were UNconditionally replacing existing tabs instead of appending

new behaviour was to replace the existing tabs. It didn't matter if you had two tabs open or 6, if you opened a group of 4, the currently opened tabs were closed and the group of 4 opened. Opening another group of three closed the existing group first, then opened the group of 3.

This behaviour led to the 10 dataloss bugs seen in Bug 203960 blocks:
Bug 209290 DHTML sites - dataloss bug caused by new groupmark behaviour (replace instead of append)

up to 
Bug 219725 groupmarks that contain a redirected web site disable the back button

and Bug 208278 Loading group of tabs from bookmarks closes all other tabs
Opened: 2003-06-04 07:56 PDT

This bug got fixed by implementing the 'conditionally' in 
Comment #108  2003-09-23 00:10 PDT and Comment #118   2003-11-29 11:56 PDT

After half a year of having removed the old behaviour an UI was checked in to enable choosing to restore the old behaviour:
 
When opening a bookmark group
[ ] Add Tabs   [x] Replace Tabs
This UI is still seen in Seamonkey, I recommend to select [x]Add Tabs, as replacing still loses some tabs in History.

Firefox2 doesn't have the group concept, or doesn't call it a group.
You can save 'All Tabs' creating a new folder in your Bookmarks.
You can open any folder in your bookmarks 'Open All'

Comment 125

[Prognathous]

(In reply to Peter Annema ("jag"), comment #0)
> From a usability study we've learned that users find it confusing that bookmark
> groups open in additional tabs instead of replacing the existing set of tabs.

What usability study would that be? You might want to share it with Zak Greant from the Mozilla Foundation, as he couldn't find any such study:

https://bugzilla.mozilla.org/show_bug.cgi?id=243740#c10

The introduction of this dataloss-inducing feature into Mozilla is nothing but a farce.

Prog.

Comment 126

[Asaf Romano (gone)]

Note https://bugzilla.mozilla.org/show_bug.cgi?id=175124

Comment 127

[tech]

(In reply to comment #124)
> That's the way Firefox is made, you are a bit late.
> Install some TAB extensions, or use about:config to set
> browser.tabs.loadFolderAndReplace to FALSE
I'm glad to be using Seamonkey instead of Firefox, as IT permit to choose and easily configure everything about tabs exactly as I want, without being subject to arbitrary decisions depending on pseudo "usability study"