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

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?

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.

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

See new meta bug 159431.

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

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.

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

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.

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