Closed Bug 160980 Opened 23 years ago Closed 22 years ago

Personal Toolbar Bookmarks vanished

Categories

(SeaMonkey :: Bookmarks & History, defect)

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

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 162593

People

(Reporter: j.bruton, Assigned: bugs)

References

Details

All but the default Bookmarks folder vanished on restart. No machine crash or application crash prior. Quit Mozilla, shut down machine, boot, launch Mozilla, no toolbar favorites. Bookmarks added to the bookmarks folder were retained, no user added folders, or bookmarks within those folders retained.
No longer able to DnD url to personal toolbar, right click-new folder.
Jeffrey, what Build ID are you reporting this bug against? In the future, please consider using the Bugzilla Helper at [http://www.mozilla.org/quality/help/bug-form.html] to report bugs.
Severity: normal → critical
Keywords: dataloss
Same behaviour for me. I didn't quit Mozilla by hand but I just logged out. Build ID: 2002072203
Build ID:2002072203, same as Greg
Jeffrey, if you examine your Bookmarks.html file by hand, are your bookmarks still there?
I have the same problem with build 2002081304. I installed mozilla on top of a previous build (20020803 I think). It happens with both an old profile and a newly created one. Bookmarks.html seems valid (I have the PERSONAL_TOOLBAR_FOLDER attribute set to true). The bookmark window disable the menu entry for personal toolbar when the personal toolbar folder is selected. So Mozilla do recognize the setting even if it doesn't display it. Also, setting another folder to be the personal toolbar works until you restart Mozilla. Then it disappear again.
First, I forgot to mention that I was using WinXP and not a Mac. So I don't know if my problem was actually the same (at least the symptom was the same). I tried to uninstall Mozilla and reinstall it. This didn't help. But, some files from the previous installation were left. So I uninstalled Mozilla, move the remaining files in an other place and reinstalled Mozilla. Now everything works fine. After checking what the remaining files were and comparing them with the new installation, I found out that the file compreg.dat in the components directory was the one giving problem. Sure enough, if I replace the new file with the old one, Mozilla fails to work (personal toolbar missing, middle-click showing a new tab only half the time, the other half, the page didn't load, etc). If I put the new one back, Mozilla works again.
Nahor, are you saying you installed a new Mozilla application version into the same directory as an older version? Jeffrey, is this what you did, also?
Yes I installed it in the same directory. If the directory isn't cleaned before the install, Mozilla doesn't work well. If the directory is cleaned, it works fine.
Then this is a dup of that bug, wherever it is.
Severity: critical → normal
Keywords: qawanted
Whiteboard: DUPEME (installing Mozilla app over old installation)
I'm sorry, but I don't get it: The first bug report was on the OS X version. Here the usual installation is dragging the Mozilla folder to the Applications folder (which IMHO does not qualify for "installing over an older version", as you get a new folder). Then someone else (even with a different OS) tells you that he has similar symptoms when installing over an older version. Why does this mean that it's a dup?
I never used a mac so I'm just going to wild guess. I assume that on a Mac, you have a way to "upgrade" an application to a newer version without wiping out your configuration. I know that on PC, when you install Mozilla on top of a previous installation, the installer goes in "upgrade mode" or something like that. The upgrade doesn't correctly fix the file "compreg.dat". That were my problem came from. Doesn't Mac also has such a file? Is it automatically overwritten when you "upgrade" Mozilla?
*** Bug 162977 has been marked as a duplicate of this bug. ***
*** Bug 162639 has been marked as a duplicate of this bug. ***
re comment #10: yeah, I dunno which one, but I did managed to find two dupes of this :p This only happens lately, probably to builds between mid July to August 12. With earlier builds I have no problem installing a newer build as long as I uninstall the older version first. But with recent builds I will have to clear the original Mozilla directory first, or the personal bar won't show up and Mozilla would crash if I try to access the Internet Search pane in the preferences dialog.
I never had this problem before. I always uninstall Moz before installing a new one. What happends is that besides the bookmarks the back and forward button dissappears too. So the summary should be changed. The status whiteboard is not correct, this happends also if you uninstall Mozilla. Only solution is too totally delete the c:\program files\mozilla.org
Changed "Platform" --> "All" & "OS" --> "All" Due to the duplicate bug #162639 which affected Win2000 & bug #162977 which affect WinXP.
OS: MacOS X → All
Hardware: Macintosh → All
*** Bug 163009 has been marked as a duplicate of this bug. ***
related: bug 162997 bug ??? (accessing Internet Search pane in Preferences dialog after installing a new build crashes Mozilla.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
This seems to be a duplicate of bug 162593, even though that bug seems like it's completely unrelated. Try deleting components/compreg.dat, and see if that fixes the problem. It did for me.
Not entirely clear how this add comment works, where your name goes, but I'll try this: using XP, build 2002081612, installed after uninstall of prev build, in same directory which was left. New build did not show bookmarks in either pulldown (top line or third) but go into "Manage Bookmarks" and it was there. Subsequently, bookmarks appear under one or the other or both or neither of the pulldown titles, each time app is opened - random? - hard to tell. Whenever they don't appear at all, launching a bookmark on the "manage bookmarks" window causes them to reappear on one or the other of the pulldowns. hope that's clear.
*** Bug 163397 has been marked as a duplicate of this bug. ***
*** Bug 163533 has been marked as a duplicate of this bug. ***
*** Bug 163593 has been marked as a duplicate of this bug. ***
I wonder if this will affect everybody that installs 1.1 when its released. Even though you uninstall the old one this happends.
*** Bug 163622 has been marked as a duplicate of this bug. ***
Does anyone not agree that this is a dupe of bug bug 162593? Deleting components/compreg.dat fixes the problem. Bug 163397 confirms this, and comment 16 in this bug supports this.
Sounds like the same solution, but they dont mention anything about back and forward buttons dissappering. Maybe solving that bug solves this one too.
*** Bug 163634 has been marked as a duplicate of this bug. ***
And if yes, then bug 162593 should be a dupe of this one...
Re: comment 30 If they are duplcates, this should be marked as a duplicate of bug 162593, not the other way around. Even though this bug has the lower bug number, bug 162593 has a summary that indicates the true problem (though someone could add this bug's problems to that summary), is in the correct component, and has several Netscape people looking into it (and on the CC list). This bug has none of those attributes.
Duping to bug 162593 based on my remarks in comment 31, and the many confirmed reports of fixing by deleting components/compreg.dat. *** This bug has been marked as a duplicate of 162593 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
If deleting the .DAT file is the supposed fix, then why does 1.1B reinstall provide the proper operation without deleting/replacing a local data file?
Keywords: dataloss, qawanted
Whiteboard: DUPEME (installing Mozilla app over old installation)
v.
Status: RESOLVED → VERIFIED
Re: comment 33 This bug was reported on August 8. 1.1beta was released July 22. Most likely this installer bug appeared after that point, which is why reinstalling 1.1beta works. Not deleting the file and reinstalling a newer version probably will not work.
*** Bug 162575 has been marked as a duplicate of this bug. ***
*** Bug 163090 has been marked as a duplicate of this bug. ***
Said not deleting file "should" fix things. That isn't the case. I reported the earlier file and kept trying builds and then putting 1.1b back when they failed. I was waiting for the install to resolve the issue and it hasn't for a month plus that the bug has been known. After getting this follow up I thought I would check it out again and delete the file. That works fine. That is the only thing that works!!!!! So you guys have a bug here that is as annoying as all get out that could drive away the appliance types from using Moz. And your best shot is that a later install will "probably" fix things. That remark is wrong at 92 levels!!! And I wouldn't consider 1.2A for release if this bug survives. BTW, the replaced file is 4 K smaller than the original. Didn't do a compare on the files--just to busy a file to want to love browsing.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.