55166 - Bookmark descriptions disappear on start

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect, P1)

Description

[Weyfour WWWWolf (Urpo Lankinen)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.13 i686; en-US; m18) Gecko/20001002
BuildID:    2000100214

I edited bookmarks to include descriptions. Then, I closed Mozilla. Bookmark
descriptions were saved (checked the ~/.mozilla/default/bookmarks.html and they
were there). When restarted Mozilla, the bookmark descriptions had disappeared completely.							

Reproducible: Always
Steps to Reproduce:
1. Open "Bookmarks->Manage Bookmarks..."
2. Add descriptions to some bookmarks (most of mine just said
   PRIVATE, but in the end results, they didn't matter.)
3. Close window. Exit Mozilla.
4. Start again, open bookmark manager again.
5. Don't gaze too long at the Abyss, for Abyss will gaze at you.			

Actual Results:  Description fields were all empty.					

Expected Results:  Description fields should NOT have been empty. =)							

This happened with both Classic and Modern skins, so I guess
this has nothing to do with the sunspots.
Happened in both RedHat 6.x and Debian potato-slightly-updated.

Comment 1

[gary_Cope]

I can confirm this on win98 also. Afer closing mozilla and restarting,changes to
bookmark descriptions had disappeared. Change os to all ?

Using buildID 2000092908 win32.

Comment 2

[Claudius Gayle]

here's a little data loss for ya. This went out on PR3, confirmed with 2000092909 linux build.
damn win98 with 2000100408 branch build too -->All/All

Comment 3

[don]

Oh hell.  When did this break?!?  Ben, should rjc get this bug?

Comment 4

[Robert John Churchill]

I'll take this.

Comment 5

[Robert John Churchill]

Attachment: Keep last bookmark/folder in a nsCOMPtr<> and only null out when next item is hit

Comment 6

[Robert John Churchill]

Chris, care to review the diff?

Comment 7

[Chris Waterson]

No need to initialize nsCOMPtr's to nsnull; they're that way by default. Fix
that, r=waterson.

Comment 8

[Stuart Parmenter]

r=pavlov

Comment 9

[Michael La Guardia]

marking rtm-.  This is a moderately weighty patch for pretty minor benefit at
this stage of the game.

Comment 10

[Robert John Churchill]

PDT: I thought that loss of user data was very important...??



The changes in the patch are actually very small (trivial, even), I'm not sure 

why you think the patch is weighty. [The patch is a context diff; only the lines 

beginning with "+" and "-" indicate a change.] Also, the patch has been checked 

into the trunk with no problems.



Want to reconsider?

Comment 11

[Claudius Gayle]

PDT, please slap two plusses on this baby. I can't tell my friends I worked on mozilla
bookmarks if we rtm like this.
Bookmarks are one of the most sticky things in a browser - it's the first thing people
personalize, let's not screw them up with data loss.

Comment 12

[selmer (gone)]

rtm-, we're not looking for patches of this size to correct a problem of this 
nature.  We have no feedback from PR3 that this is a problem being experienced 
by users.

Comment 13

[Robert John Churchill]

Fixed on trunk, rejected for rtm branch, FIXED

Comment 14

[Angela Butler]

Added branch accept to status whiteboard

Comment 15

[Angela Butler]

Please check this in on the branch ASAP. Thanks in advance,
.Angela...

Comment 16

[Alec Flett]

fix checked into the branch now too.

Comment 17

[lchiang]

claudius - you wanted it and you got this one fixed :-)
Please verify on branch/mtest builds and on the trunk builds.

Comment 18

[Claudius Gayle]

VERIFIED everywhere on everything. Seriously, trunk build 2001010908 and branch builds
20010104(win) and 20010108(mac). Woohoo!

Comment 19

[rpallath]

Verified on Netscape6 commerical build (03/15/2001) on x86 Solaris 2.7 (with
min patch level) and sparc Solaris 2.8 (max. patch level).

Works fine.

 [tag: -r Netscape_6_0_OEM_BRANCH -D "03/06/2001 22:00:00"
 PSM: 1.4 (PSM_1_4_N6) & NSS 3.1 (NSS_3_1_RTM tag)