Closed Bug 208278 Opened 22 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.