Closed Bug 134800 Opened 22 years ago Closed 21 years ago

Opening a bookmark group clobbers all open tabs

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: ian, Assigned: caillon)

References

Details

(Keywords: dataloss, Whiteboard: [adt2 rtm] [FIXED ON TRUNK][verified on trunk])

Attachments

(4 files, 4 obsolete files)

Example screenshot - before case
144.64 KB, image/png
Details
Example screenshot - during case
132.47 KB, image/png
Details
Example screenshot - after case
18.91 KB, image/png
Details
Branch patch
5.31 KB, patch
caillon
: review+
caillon
: superreview+
caillon
: approval+
Details | Diff | Splinter Review 
I opened a bunch of tabs that I wanted to read and then also opened a bookmark
group. Boom, I lost all the tabs I had open, and, unlike normal bookmarks, could
not hit the back button to get my data back.

Opening a bookmark group should not close all the already open bookmarks. I
think it should open the first bookmark into the active tab and then open all
the other pages as new tabs.
Keywords: dataloss
Blocks: bm-group-tracker
1. that's not strictly true, you can just hit back(per tab) and see your old
pages, at least in my experience.

2. there was evil that happened(dataloss) when the number of tabs your were
opening were different from the bnumber you had open. There's discussion of that
in one of the older muddled bugs. We need that info here but I'm tired.
ahh bug 119599 of course. If you open a bookmark group of n tabs when you only
have <n already open, you are going to lose your previous tabs, and one can
legitimately claim dataloss. 
Platforms/Os All/All.

nominating. this bug will eventually bite everyone who uses tabs and/or bookmark
groups. These are probably 2 out of the top 3 new browser features (from Joe
user perspective) so let's try and get them right. This is definitely the kinda
thing to fix before RTM.
Keywords: nsbeta1
OS: Linux → All
Hardware: PC → All
okay i mucked that up in comment #2. if you open a tab group smaller than the
number of tabs already open you lose the extra tabs. the other way around works
fine.
The other way around doesn't work.

If you have 3 tabs open and you open a bookmark group with 5 bookmarks, you
should end up with 7 tabs (the 2 you had open in the background, and the five
new ones from the bookmark group; the tab you had open should get replaced by
the first of the pages from the bookmark group).

At the moment you end up with 5; any in the background are lost.
I think that in Ian's example, you should end up with 8 tabs in the end (3
existing plus 5 new).  When I bookmark a group of tabs, I'd want those tabs to
show up without disturbing whatever I alread have open.  I use 'open tabs in
background', so maybe wanting all new tabs is just how I browse.  I guess I
could live with replacing the active tab also; at least _everything_ wouldn't
get replaced...
Replacing the current tab is for consistency with how normal bookmarks work. If
you have a bookmark group with exactly one bookmark it should act exactly like a
normal bookmark. (IMHO, anyway.)
As Hixie says, this is the intended, correct behavior. resolving as invalid.
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: nsbeta1 → nsbeta1-
Resolution: --- → INVALID
Er.

As the person who filed this bug, I don't say it is the intended, correct
behaviour. The current behaviour leads to dataloss, and is inconsistent with the
behaviour of normal bookmarks.

I assume you closed the wrong bug?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
I agree that this bug is invalid.  We're using a "replace" metaphor here.  
When you open a single bookmark, it replaces the current Web page.  When you 
open a tab group, it replaces the current tab group.  The fact that there is 
no way to recover these tabs may in itself be covered by a separate bug (or 
perhaps a redesign of session history).

In other words, you're experiencing data loss, but you're jumping to a 
specific solution to the problem that violates the metaphor we're using.

I would argue for CTRL+clicking of a bookmark group doing an extend rather 
than a replace (opening in a new window or extra tabs based off the use 
windows vs. tabs pref).

I don't understand why a one-bookmark bookmark group should result in a
different behaviour from a single normal bookmark.
although i understand both sides of the coin, it seems that being additive 
rather than destructive will irk users less.  The bookmark replace 
metaphor works fine for the single window browsing experience,  
however, the tabbed browsing experience may not adapt to that so 
literally.  One suggestion would be to offer a way for users to select an 
"open this group in new window" option to allow them to store 
'workspaces', by flaging a groupmark in the groupmark dialog 
(workspaces or 'home sets' - as described by the user scenarios we 
envisioned) as a groupmark that always opens in new window.  However, 
I believe that by default appending tab groups to an existing tab group will 
create the least amount of frustration, even if it creates a mess - it is a 
mess the user asked for by virtue of calling upon the groupmark.

The current 'workspace' destructive behavior is definitely bothersome, and 
could harm tab browser acceptance.   I think we should reconsider this if 
it's not too late.
Thanks marlon.  I agree this is something that we should get in.  I'm bringing
this up at nav triage today.
Keywords: nsbeta1- → mozilla1.0.1, nsbeta1
As a fresh perspective from someone who has just started using Mozilla at 1.0, I
just have to say this kill-everything-else-on-open-group-bookmark behaviour is
really bad. The first time this happened I went "WTF? Where did all my tabs go?"

Any time that happens, it says to me the metaphor being used is broken. You
might be thinking replace as the implementers, but that's sure not what a normal
user is going to think is going to happen.

The arguments in favour tend to say:
A) Use the back button (Response: That's rather lame, it means you can't keep
what you have as well as open the group)
B) Users will get confused with lots of tabs (Response: Not true, and even if it
were, losing your current tabs is immensely more confusing) 

It's so annoying that out of all the quibbles in 1.0, this is the only one I've
thus far been motivated enough to comment on. However, whilst I'm here I might
as well mention a handful of other things.

There are other implementations of tabbed browsers out there that have had a
number of years to iron out the UI quibbles - the main one that I use regularly
is NetCaptor (http://www.netcaptor.com/), which is effectively a tab-browser
wrapper that sits on top of IE. I like Mozilla a lot, and am aiming to use it
almost exclusive for a few months to give it a good go, but because of using
NetCaptor, there are some areas of the tabbed-behaviour that stand out to me as
not being quite as slick as they could be, namely:

1) The groups closing everything else behaviour described above.
2) The existence of group bookmarks as differentiated from normal bookmarks.
Early versions of NetCaptor did this too, but now they have a much nicer idea,
which is under any bookmark folder group the first item says "Open all
favourites", and if you choose that it opens any bookmarks in the current
bookmark folder. This does away with the need for group bookmarks, and it means
that you can just move bookmarks into and out of (say) a "Check the morning
news" folder. This is much nicer (to use, as well as implement I would imagine).
It would also simplify "Manage Bookmarks" tool I imagine too. It also does away
with the need for the "File as group" tick box.
3) When tabs load, they give a colour indication of how loaded they are (like a
very simple reflection of the progress bar that shows in the status bar). So
when a group is opened, initially every tab opened starts out with a red block
in it's tab. As it loads it goes yellow (with 3 steps of yellow), and then when
it is totally finished it goes green. This allows a group to be opened using a
dial-up modem, and then for the user to go get a coffee or whatever, and come
back and start reading only those pages that have finished loading, and as pages
are being read the other ones continue loading, and it's quite pleasant to use
as you can just go from loaded page to loaded page.
4) Tabs can be on multiple rows, as opposed to Mozilla where there only ever
seems to be one row that only gets more and more crowded. This is especially
useful when you have about 20 tabs open on 3 rows or so, since you can see what
everything is (probably get the first 15 characters of every HTML title tag).
Furthermore, the width of each tab is reduced if the title of a page is small
(which helps if there are lots of tabs), whereas with Mozilla each tab appears
to get a certain amount of width that that is the same for each tab.
5) Ctrl-N opens a new tab, rather than a new window. In fact you can't open a
new window, and if the tab implementation is good, you never need to or want to,
and I just find the opening a new window a bit annoying.
6) An option to load whatever tabs were open when the browser was closed. This
means you can quit the browser, log out, and then come back later and reopen
whatever tabs were open before and finish whatever you hadn't finished reading -
it's quite handy.


Anyway, I know there's lots of stuff in the above, and that it's about million
times easier to suggest things than it is to actually build them, so please take
these suggestions in the friendly spirit in which they were intended.
Let's keep this bug report focused on this defect, which I have been persuaded
is a critical, data-loss scenario if you have form data in the tabs. I suspect
we will be hearing a lot more reports about this behavior if we don't fix it
while making groupmarks more discoverable.  If a simple patch could make these
additive, I think it would be worthwhile to take for MachV.
Attached patch Additive fix v1.0 (obsolete) — — Splinter Review 
Small patch per marlon's suggestion to make us append tabs to our current tab
list.  I've tried this locally and it makes for a hell of an improvement.
Attached patch replacing fix (obsolete) — — Splinter Review 
This patch is in between the current and christopher's behavior.
It is intended for UE testing.
when the user load a bookmark group, tabs on the right of the selected one are
replaced (included the selected one). New tabs are added only if necessary.
Replaced tabs can be restored with the back button.
- loading bookmark group won't increase the number of tab 
- this is well suited for the scenario in which the user has a number of tab
greater that the number of bookmark in the group. He can use this bookmark
group as a working set by selecting the first tab, loading the group, working
in the loaded tabs, then reselect the first tab, reloading the group... etc.
- this way, a group of 1 element is loaded the same way as a single bookmark.
I am not sure if I have been clear but with my patch, if #tabs is 5 and the
group contains 3 bookmarks for instance, if the user select the first tab and
load the group, the last two tabs are not closed/modified.
In addition, a bookmark group can be easily loaded without replacing any
existing tabs by hitting CTRL-T as we already do for single bookmark.
Attached patch replacing fix (obsolete) — — Splinter Review 
simpler fix.
When I will have time, I will attach another implementation that inserts  the
bookmarks
Attachment #87358 - Attachment is obsolete: true
Nav triage team: nsbeta1+/adt2 rtm
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 rtm]
Appending new tabs could be covered by the "missing" open in new tab option.
The behaviour I think Pierre is describing is, IMHO, too confusing. The
behaviour I believe marlon is describing, and the one I am supporting, is IMHO
the simplest for users. Namely: The one bookmark bookmark group case should act
exactly the same as a single bookmark, and any additional bookmarks in the
bookmark group should be appended on the end.
If I read that correctly, then the result in some scenarios would be a group
that is not grouped. In other words, if the first bookmark in the group acts
like any other bookmark on the active tab, and any subsequent bookmarks are
opened on the end of the tab bar, then there may be intervening tabs that are
not part of the groupmark, so the group would not be contiguous in the tab bar.
 I think it is important for groupmarks to open in contiguous tabs, regardless
of whether they are all appended, open in a new window, or are inserted at the
active tab location. 
I agree with Peter, group tab should not be split.
The problem with the current version of the patch by christopher is that group
tab are systematically appended, even if the browser contain one tab
'about:blank'. It means that it will not be possible to use |OpenBookmarkGroup|
after opening a new window and filling it with the bookmark group, since the
home page will still be there.

I have investigated an implementation that does the following:
- replace the selected tab by the first bookmark in the group
- insert the others on the right of the selected ones.
In addTab, I simply used |insertBefore| instead of |appendChild|

Unfortunately, I hit a bug about tab ordering.
Let's say I have the tabs A and C
I insert a tab B between A and C
results in the 'tab bar': B, A, C instead of A, B, C
Now, If I look at the DOM level, B is the 'nextSibling' of A and the
'previousSibling' of C, as expected. In other words, in
gBrowser.mPanelContainer.childNodes: [0]=A, [1]=B, [2]=C.
In conclusion, the insertion is correctly performed but the display is wrong.
Could anybody point me to the place I could look to investigate more?
Hixie, we're suggesting something similar.  The patch here will append all tabs
to the end of the tab list.  IMO, this is slightly better since it has less room
for confusion: e.g., if you have 5 tabs open, and the 2nd tab is active, if we
change one tab and append the rest, then the groupmark has become 'separated'. 
If you append the rest directly after the 2nd, then you are shifting existing
tabs around and that could lead to confusing.

->me since I've been the one pushing this to get in for Mach V, and I've got the
patch.
Assignee: ben → caillon
Status: REOPENED → NEW
Pierre, I've already investigated that and I've posted to the npm.browser (and
it was crossposted by someone else to .ui) and in comment 25 why we decided that
behavior was sub-optimal: We don't want to move any tabs that the user has set
up.  I appreciate your efforts, but please let's not turn this bug into a patch
war.  It is going to be an uphill battle trying to get any patch at all in this
late in the game.
Status: NEW → ASSIGNED
I'll second that; this bug is just to correct a glaring fault with a fix we vsm
quickly land for MachV.  What the optimal behavior should be in future releases
is a longer-term topic.
Well, we want the optimal fix on the trunk, obviously.

caillon: I see the problem, but if we decide that we want to keep tabs together,
I prefer the idea of inserting the 2nd and subsequent tabs after the current one
rather than just adding the tabs at the end. I hadn't really considered that we
would want to keep tabs from a bookmark group together, but I could see that
that would be a laudable goal.

To prevent user confusion, a one bookmark bookmark group should act exactly the
same as a single simple bookmark.
I tend to agree with Christopher Aillon & Ian 'Hixie' Hickson.

What some other tabbed browsers do that I've seen is append only to the current
tabs (i.e. do not replace the current tab at all, even if the group only has one
bookmark). This has the benefit of always keeping all the new group tabs
together, but as Hixie pointed out this is different behaviour to normal
bookmarks if there is only one bookmark in the bookmark group.

Frankly though, I personally don't care whether the current tab gets replaced or
not, or whether the group is split or not, as long as any other non-active tabs
that were open at the time the group bookmark was selected are not
destroyed/lost/changed - everything else is secondary to this.
Comment on attachment 87322 [details] [diff] [review]
Additive fix v1.0

sr=blake
Attachment #87322 - Flags: superreview+
Comment on attachment 87322 [details] [diff] [review]
Additive fix v1.0

r=jag
Attachment #87322 - Flags: review+
Landed on the trunk.
Priority: -- → P2
Whiteboard: [adt2 rtm] → [adt2 rtm] [FIXED ON TRUNK]
Target Milestone: --- → mozilla1.0.1
> What some other tabbed browsers do that I've seen is append only to the current
tabs (i.e. do not replace the current tab at all, even if the group only has one
bookmark).

Nick, really?  What browsers are these?  Examples are always good.
I'm glad to see the immediate fix go in, and agree that we want to get the trunk
optimal ASAP.  I think that keeping the tabs loaded by a groupmark contiguous is
fundamental; without that, they are not a group.  There may be some benefit in
having them work exactly like bookmarks in the unlikely edge case where they
contain only one URL, but that shouldn't drive the design choices for the
typical scenarios.  It is important for the groupmarks to behave predictably, so
I hope nobody wants them to behave differently depending on the number of URLs
they contain.  I could personally live with loading the first URL in the active
tab and inserting the others, but I suspect that appending them all is the
safest choice for the next release.  The results would then be apparent and
consistent regardless of the current active tab. With replacement, I worry that
people would either not realize that one tab was overwritten, or not easily find
the group that was loaded.  That's something we'll need to test with target
users to find out.
Keywords: adt1.0.1
Priority: P2 → --
Target Milestone: mozilla1.0.1 → ---
Comment on attachment 87368 [details] [diff] [review]
replacing fix

I apologize for having jumped in it so abruptly by but when I did it, there was
no mention of the newsgroup discussion in this bug report and the only agreed
drawback of the old behaviour was dataloss when #tabs > #bookmarks. I stated
that the patches I provided were for UE testing only. In any case I did not
want to begin a patch war. I have seen some examples in the past and they only
had one effect: to delay mozilla.
The new behavior is really better than the previous one, but my vote goes for
the 'insertion method' for the optimal patch, since one still have the
possibility to append tabs at the end by adding a new tab.
Attachment #87368 - Attachment is obsolete: true
Re comment # 33:

> Nick, really?  What browsers are these?  Examples are always good.

Yep, for sure - there's two - NetCaptor and CrazyBrowser (both are tabbed
browser wrappers on top of IE, so their main reason for existence is adding tabs
and groups, and such these two things are kind of their "core competency"). URLs
are http://www.netcaptor.com/ and http://www.crazybrowser.com/

To make things easy so that you can see how they behave, I've made some PNG
screenshots. I'm attaching these to this case (I hope that this is OK, don't
know whether this is the done thing or not, so please forgive me if I'm doing a
something wrong).

There are 3 files for NetCaptor (I also have 3 for CrazyBrowser that look
virtually identical, but attaching them too is probably overkill, so I haven't).

The three images show the before, during (opening everything in a 1 bookmark
group, that consists appropriately enough of the bugzilla site), and after cases.

Note that the selection method of groups show in the during image is different
(and better IMHO) to Mozilla, in that everything in any bookmark folder can be
opened at once, thus avoiding the need for bookmark groups (but this is already
being discussed in another bug)

Note also that the active tab is not altered/lost/replaced, even though there is
only one bookmark (i.e. it is additive only).
selecting to open everything in a 1 bookmark group
selected 1 bookmark group is in the process of loading in a new tab
There is a bug in the implementation of the fix that was checked in.

It correctly appends all the bookmarks from the bookmark group, and focusses the
first one, which is brilliant -- I like that behaviour, and retract my previous
requests for another behaviour.

However, it also clobbers the tab that was focussed when the bookmark group was
opened. That tab ends up pointing at about:blank. Its session history is not
wrecked though, and clicking back will return it to the previously shown page.
This is a confusing bug and should be fixed.

Do you wish me to file a new bug?
Hixie, yes please file a new bug and assign to me if you like.  I see the
intended behavior -- appending tabs and focusing the first tab in the group, but
my previously focused tab never changes as you say.
I, like Christopher, do not see the about:blank problem.

I like how the whole tab group is appended.  The single tab 'group' needn't act
like a normal bookmark, because it's still a 'group', distinct from a standard
bookmark.

However, I do want to note that focusing the first tab in the group after
opening it is annoying.  Since I use 'open tabs in background', I expect any tab
(or tab group) to do just that.  Should I file another bug, or will the future
refinements in this bug take that pref into account?
FWIW: I think that the focused tab should be replaced by the 1st tab in the
group, and all other tabs in the group inserted between the focused tab and any
other tabs to the right.  This keeps the tabs in a contiguous grouping (which I
don't think anybody really objects to) but keeps the usage of bookmarks
consistent with how single bookmarks work.

With a single bookmark, the currently focused tab is replaced, and as Hixie
points out in a few comments, a group bookmark comprised of only one bookmark
should behave the same as a regular bookmark.  I think that group bookmarks
should behave as close to single bookmarks as much as possible (to avoid
confusion), but also maintain their grouping and prevent dataloss.  This seems
the most logical way of doing it to me.  (The back button would then change the
focused tab back to what it was previously, but the other inserted tabs would
remain.)

If tabs are to continue to be added to the end of the current tabs (as they
currently are), rather than the replace/insert behaviour suggested above, then
changing tab focus to the 1st tab in the group should be based on the already
existing tabbed browsing preference ""Load links in the background".

Having said all of that - although I preferred the old replace behaviour to what
we have now, I do acknowledge the validity of the current approach and recognise
that a "hanging left tab" (blank or Home page - which I always have to close 
since it's an annoyance) is a better thing to live with than any potential
dataloss which has now been prevented.  I just hope we can tweak this a bit more
to get the best of both worlds.

> With replacement, I worry that people would either not
> realize that one tab was overwritten, or not easily find
> the group that was loaded.

Since they would be looking at the focused tab, and its content would change
immediately after they loaded the tab group, I'm not sure I see why there would
be any confusion as to what happened.  Nor do I see why they would not be able
to find the rest of the group - the name of the inserted sites will appear in
the tab labels.  (I can only really see this being a problem if they aleady have
a large number of tabs open, shrinking the width of the tabs and making the
short amount of text not very useful.)

As for comment 40, I do not see the about:blank behaviour reported.  For me, the
focused tab remains as it was and there is no bug.  (2002061707 / XP)
Attached patch Trunk patch (checked in) (obsolete) — — Splinter Review 
Fixes a small performance issue with loading tabgroups.  Ian was right, we
tried loading about:blank into the current tab in some situations for no good
reason other than to get the current window.  This was then exposed when we
started appending tabs instead of clobbering them.  This patch is for the
branch and includes the previous fix that went in on the trunk already.
Attachment #87322 - Attachment is obsolete: true
Comment on attachment 88020 [details] [diff] [review]
Trunk patch (checked in)

Whoops, I mixed up my filenames.  This is the TRUNK one.  The branch one is to
follow.
Attachment #88020 - Attachment description: Branch patch → Trunk patch
Attached patch Branch patch — — Splinter Review 
THIS one is the branch patch.  It includes the fixes already in the trunk (that
the previous patch doesn't)
Comment on attachment 88020 [details] [diff] [review]
Trunk patch (checked in)

r=blake
Attachment #88020 - Flags: review+
Comment on attachment 88020 [details] [diff] [review]
Trunk patch (checked in)

sr=jag if you leave out that first hunk
Attachment #88020 - Flags: superreview+
Comment on attachment 88020 [details] [diff] [review]
Trunk patch (checked in)

Checked in on the trunk, sans the first hunk and with another minor change that
jag had me make but forgot to note.
Attachment #88020 - Attachment description: Trunk patch → Trunk patch (checked in)
Attachment #88020 - Attachment is obsolete: true
i ran through the following test cases:

a. open bookmark group from Bookmarks menu.
b. open bookmark group from Personal Toolbar.
c. open bookmark group from Bookmarks Sidebar tab.
d. test bug 152278 to make sure about:blank did not occur.

for (a), (b) and (c), opening the bookmark group was *additive*, not
destructive. and (d) turned out fine (no about:blank).

tested using 2002.06.18.0x commercial trunk bits on linux rh7.2, mac 10.1.5 and
win2k.

marking this as fixed, if that's alright!
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Whiteboard: [adt2 rtm] [FIXED ON TRUNK] → [adt2 rtm] [FIXED ON TRUNK][verified on trunk]
Comment on attachment 88021 [details] [diff] [review]
Branch patch

Transferring r/sr= from the trunk patches.
Attachment #88021 - Flags: superreview+
Attachment #88021 - Flags: review+
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020618
Build: 2002061808

If I open a empty browser window and then click on a bookmark group, I get a
empty tab with about:blank in the location bar.


Adding adt1.0.1+ on behalf of the adt for checkin to the 1.0 branch.  Please get
drivers approval before checking in. When you check this into the branch, please
change the mozilla1.0.1+ keyword to fixed1.0.1
Status: RESOLVED → VERIFIED
Keywords: adt1.0.1 → adt1.0.1+
Tobias, does your problem from comment 52 happen both with and without the patch?
So it seems to me that comment 52 is because this patch implements something
slightly different from what comment 0 suggested.  Comment 0 suggested that the
first of the bookmarks in the bookmark group should be in the active tab, and
all the rest should be in new tabs.  It seems (based on my testing of the trunk)
that this patch causes *all* the boomkarks in the group to be opened in new
tabs.  This is (as comment 52 suggests) somewhat annoying when one wants to use
boomark groups to replicate a group of tabs.  However, using the active tab
might not always make sense, either, if the active tab is somewhere in the
middle of a large group of tabs.  Perhaps what we really want is (1) if there is
only one tab currently open, then open the first bookmark in the group in that
tab and the rest in new tabs (2) otherwise, open all bookmarks in new tabs. 
This seems to me to produce a reasonable result in all cases, without dataloss
(presuming the back button works in the first tab).

The behavior in comment 52 does seem annoying.  Any opinions on whether we're
better off with or without the patch, or whether you think it's low enough risk
for a different patch?
All I know is that when I open Mozilla, then open a tab group, I'm left with a
tab at the left that I don't want, and always have to close.  In such a case I
definitely want the "active" tab replaced.

But - this bug is marked FIXED.  Discussion should be carried on in a different
bug.  I have already opened a couple of related bugs from the fallout of this
one a week ago (bug 153016 bug 153018), but the current discussion seems
different again.
Re: comment 55

David, it was decided among some of the pixeljockeys members (though not in any
official meeting) that the behavior that is currently in the trunk is the least
risky, least destructive way to fix this.  In particular, the module owner, UE,
and several members of the navigator team feel that for the time being, this
behavior is good enough and should be checked in to the branch, however we
should definitely revisit this issue on the trunk when we have more data as to
what the optimal solution is.
Comment on attachment 88021 [details] [diff] [review]
Branch patch

I just talked to Asa who gave me verbal a=asa for this patch.
Attachment #88021 - Flags: approval+
Landed on to the branch last night.
Keywords: mozilla1.0.1 → fixed1.0.1
Target Milestone: --- → mozilla1.0.1
VERIFIED Fixed for 20020711 branch builds.

IMHO this fix has been implemented all wrong and I'll be championing a different
method for the final soln' on the trunk. I'll take up that cause in bug 153016
Keywords: fixed1.0.1 → verified1.0.1
This bug has returned in recent nightlies. See bug 208278
Reopening as tests in Comment #50 no longer work as well as Comment #61
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
This is still fixed.  The original intent of the bug was to not lose your pages.
 The way that opening new bookmark groups works has changed, but your data is
still not clobbered (see comment 0, first paragraph).  The second paragraph was
subjective but there are other bugs on that.  If you feel that you want a
different behavior, well nobody is going to be happy.  There has been too much
complaints on both sides to please everyone.  This bug is FIXED.  If you want
its behavior back, file a new bug, or better yet, look at one of the dupes of it.

Re-resolving.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: