221410 - New bookmarks toolbar folder is prepended when originally already exists. Bookmarks Toolbar is blank.

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Hanspeter Niederstrasser]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6a) Gecko/20031006 Firebird/0.7+

Upon loading Firebird, a new entry for the Bookmarks Toolbar Folder (BTF) is
added to bookmarks.html.  Closing and opening Firebird prepends another BTF
entry to bookmarks.html.  The extra entries prevent Firebird from displaying the
correct bookmarks on the bookmarks toolbar

Reproducible: Always

Steps to Reproduce:
1. Open firebird (must be a 20031004 build or later)
2. Look at your bookmarks
3. 

Actual Results:  
The bookmarks toolbar is empty, although inspection of bookmarks.html shows the
contents have not disappeared.  From the pulldown menu, there are now two
entries for the bookmarks toolbar folder.

Expected Results:  
Kept the bookmarks as they were.

Attaching bookmarks.html before and after the addition of the new BTF entry.

Comment 1

[Hanspeter Niederstrasser]

Attachment: original bookmarks

Bookmarks before running Firebird

Comment 2

[Hanspeter Niederstrasser]

Attachment: modified bookmarks

Bookmarks.html modified by Firebird.  Notice the 2nd instance of Bookmarks
Toolbar Folder.

Comment 3

[Mike Connor [:mconnor]]

I'm quite sure is that this is related to pierre's recent checkin to allow
changing the bookmarks toolbar folder, along with general cleanup of that code.
 Others have been reporting this since that checkin (mostly people building on
their own, since there hasn't been nightlies in a few days) and from the checkin
comments, it could break older files.  Just set the old bookmarks toolbar folder
as the bookmarks toolbar folder again and be done with it.  Backwards
compatibility is not going to be a concern until we get close to or at 1.0. 
Before that point, this is prerelease software and standard backup procedures
should be followed.

pch, please reopen if I'm wrong on this

Comment 4

[David P James]

Export your bookmarks, save anything of use in your profile (user.js, 
cookies*, etc), hose your profile, create a new one, import your old bookmarks 
in the bookmarks manager. 
 
v. 

Comment 5

[Pierre Chanial]

there's three things here.
First, the code correctly detects that there is not a proper BTF. That's because
your first bookmarks.html file is corrupted (the BTF doesn't contain the flag
PERSONAL_TOOLBAR_FOLDER="true").
Then we should check for NC:PersonalToolbarFolder when we encounter a corrupted
file. I knew that, but I wanted to know first if there are many corrupted
bookmarks.html around.
Last, and that's a bug: we don't repair it correctly: the new BTF must have a
PERSONAL_TOOLBAR_FOLDER="true" in the new bookmarks.html.

Comment 6

[Pierre Chanial]

I fixed both issues.
But, if possible, verify carefully.

Comment 7

[Hanspeter Niederstrasser]

Verified on a fresh build from this morning.  The BTF was recognized (icons
displayed), folder duplication did not occur, and PERSONAL_TOOLBAR_FOLDER="true"
was added.  I don't know if this is important, but that attribute was added on
program quit, not on inital file read.  Since the bookmarks were properly
recognized from the beginning anyway, I don't think that'll matter.

Comment 8

[u58943]

the way the checkin for this bug works is whenever firebird is started, it
checks for this folder in bookmarks.html, if it doesnt exist it is created. In
other words in true microsoft style, you delete it, and it comes back, you
delete it, and it comes back...........

IMO Its bad way to do the fix as it shouldnt put the folder back at all if it
doesnt exist, since the reason for it not existing is almost certainly the user
has deleted it because they dont want it. The only time this folder should be
created is when NO bookmarks.html file exists and it should then create this
folder when it creates the new bookmarks file.

We had all this before when this damn folder first appeared and people couldnt
delete it at all, it was eventually fixed, but now we are back where we started
where it can be deleted but just re-appears all the time.

Comment 9

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change