User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/20020722 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/20020722 Sorry I can't be more specific, but at least 4 times my bookmarks have become corrupted and were lost completely, replaced by the default mozilla bookmarks. Reproducible: Couldn't Reproduce Steps to Reproduce: 1. 2. 3.

WorksForMe using Mac/2002082308/9.2.2.

I will comment that something like this just happened to me under MacOS X 10.2. Everything was working fine earlier today. Logged in, fired up Mozilla just now and it had reset both my preferences and more painfully my bookmarks. Up and decided to overwrite the bookmarks file without even comment or backing up the prior set. I can't recall if they've ever been reset to default before. Though I have had a couple times where Mozilla didn't get around to reading/loading its bookmarks.

Oops, should add Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1a) Gecko/20020610

Sounds like bug 164387.

*** Bug 165833 has been marked as a duplicate of this bug. ***

*** Bug 166554 has been marked as a duplicate of this bug. ***

Platform, OS -> All Confirming based on duplicates

*** Bug 167427 has been marked as a duplicate of this bug. ***

*** Bug 138930 has been marked as a duplicate of this bug. ***

*** Bug 170261 has been marked as a duplicate of this bug. ***

Does this bug have anything to do with the Mozilla quicklaunch issue - (sorry I don't know the the bug number)? I vaguely recall that I was using the quicklaunch option on the two occasions when I lost my bookmarks.

When I was using Mozilla 1.1, and launched the program before the control-icon in the taskbar was visible, there were no bookmarks available. But I never really lost bookmarks. With 1.2 200209104 it is not possible to launch "too soon".

*** Bug 171145 has been marked as a duplicate of this bug. ***

This just happened to me again after a long time not happening. I'm using Mozilla Build ID: 2002100403 on Mac OS X 10.2. Was using the newsreader which I don't normally use. Mozilla crashed and my bookmarks were "restored" to the original minimal factory defaults. This is very bad. Bookmarks are precious and should not be able to be lost so easily from my perspective at least.

Isn't this a dupe of bug 114824?

*** Bug 180195 has been marked as a duplicate of this bug. ***

Using Windows 2000 SP2, Mozilla 1.01. The sequence for me was: * Mozilla was open * An unrelated disk-intensive app was running * The system ran out of disk space and crashed. I did not know the disk was full until after reboot. * System rebooted and Mozilla started (very slowly). * Large files (unrelated to Mozilla and in a different directory) were deleted to allow system to run * Bookmarks were gone. sPh

if you aren't a driver you shouldn't set + for blocking1.3a

I thougt the idea of flag was the same as votes, my mistake. But I do want to request this as a block. Maybe not for 1.3a but at least for 1.3 There are a lot of bugs that are in some way related to this bug AND it's is dataloss (it happend to me 3 time in 2 months), i don't think this is acceptable for a stable release. These bugs are already a dup of this one: 165833; 166554; 167427; 138930; 171145 And I think the following bugs are also dups of this one: 123650; 123802; 153713; 114824; 113430; 98476; 98648; 99341; 117345; 128131; 122362; 135615; 143158; 158501; 123650; 85955; 159642; 163899; Maybe it's difficult to trace the source of the problem, but it should't be hard to solve dataloss: Hint: Somewhere in the source a function is called to open the "bookmark.html" file. There should be something like: if (openbookmarks()==false) {CreateCopyOfOldBookmarks(); printf('There's an error occured reading youre bookmark file, please send a copy of "bookmark.html.bak to mozilla so we could trace the problem');}; I more advanced user could restore his bookmarks easily. I do know it isn't that simple, but please somebody look at it.

This happened to me, just now, Mac OSX 10.2.2. All my bookmarks have been replaced by the defaults. This is a sad day. Could Mozilla not at least tell the user before it decides to trash the bookmarks? And keep a backup? // Pseudo code, no valid syntax here... function coruptedBookmarksNeedReplacing() { alert('something is wrong, so i deleted all your boookmarks'); alert('but at least i made a backup! see bookmarks.bak'); copy ($profilePath . "/bookmarks.html") ($profilePath . "/bookmarks.bak"); replaceBookmarks(); }

*** Bug 184530 has been marked as a duplicate of this bug. ***

I have not had this issue happen to me for some time now. I *beLIEve the only thing I'm doing differently is *not enabling the quick-launch feature. Is anyone experiencing this problem while *not using the quick-launch?

Yes, I have. My problem was solved by creating a new profile, then deleting the old one (I *did* leave the folder in there tho'. I never use quick launch. Still seems like something to look into.

I use linux, And there is no quick-launch, for linux.

*** Bug 184530 has been marked as a duplicate of this bug. ***

*** Bug 187625 has been marked as a duplicate of this bug. ***

I lost all of my bookmarks yesterday after Mozilla crashed. They were replaced with the default bookmarks. Happened on Mozilla 1.2.1 (the purportedly stable release): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 Running SuSE Linux 7.3, GNU Libc 2.2.4, Linux kernel 2.4.16. This is the first time it's happened to me. I use Mozilla intensively, but only recently upgraded to 1.2.1 from 1.2-beta What happened: Mozilla seemed to be slower than usual, so I quit with ^Q. When I restarted the browser, my toolbar looked different! None of my other configuration information seems to have changed. I saved a copy of my ~/.mozilla directory right after the disaster; if anyone wants it I will be glad to provide it.

Just been hit by this. SuSE linux 7.3 2.4.19 glibc-2.2.4 SuSE's rpm mozilla-1.2.1-0.i386.rpm from ftp://ftp.suse.com/pub/projects/mozilla/1.2.1/7.3-i386/ Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204 The browser had been open for a few hours, mostly offline on dial on demand with a 56k modem. The most recent thing I had been doing was showing someone the flash 'game' from http://www.idleworm.com/nws/2002/11/iraq2.shtml whilst offline. (Shockwave Flash 5.0 r47). Went back to work on a different virtual desktop. When I switched back Moz only drew graphics in the window - no text (I can't remember about the toolbars). I shut moz down, and when restarted it had the default (SuSE customised) bookmarks. All prefs seem to be intact. I've kept a copy of my .mozilla folder too.

I just like to add that this also happened to me on no less than three occasions to date using Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1) Gecko/20020826. Slackware 7.1.0(2.2.21) In my last case Mozilla was VERY slow (Java bogdown as usual) so I decided to close Mozilla down completely and restart it. All Bookmarks were there before & there didn't appear to be any problems with closing, however apon restarting, the Bookmarks were reset to default as installed!!! Disk space is not an issue as there is over 700MB free IIRC prior events(losing bookmarks) to this were under different circumstances in each case.

I beLIEve it would be a good idea to have a function automatically create a backup of the bookmark.htm file until this issue is resolved. Something similar to that found in Wordperfect. ie: bookmark.htm, bookmark.bak

This is probably bug 170539, which is now fixed. Can someone confirm?

I can confirm that this is not the same as 170539 (Chris Lyon's hypothesis in message #31). When I had my bookmarks wiped out, my prefs.js appeared unmolested. Certainly all of my email account settings were still there.

re: comment 31 I agree bug 170539 looks like its related to this bug, and might well fix it, but without a way to reproduce, I can't confirm it. I think it should be left open for now, to see if more reports appear, and since it's a part of tracking bug 123929

*** Bug 197513 has been marked as a duplicate of this bug. ***

Years of bookmarks were wiped yesterday and replaced with the Mozilla default. File prefs.js seems ok and I noticed no other changes. The day prior, my computer crashed due to a power outage -- Mozilla probably was running. My OS is Win2K, my Mozilla is 1.2a. I love Mozilla, but until automatic creation of bookmarks.bak or some such safety net is written into its code, it's too dangerous for me to use. This is by far the most critical bug I've encountered in years. I'll keep checking Bugzilla to see if, when, and how this bug is resolved, but for now, with deep regrets, I must say goodbye.

P.S. Quick Launch was running. No file named "bookmarks" contained the lost data. I didn't and still don't know how to back up my bookmarks file from within Mozilla -- is there an option for this?

This hasn't happened to me for some time now, but John you should try using a newer version of Mozilla (at least 1.3) to see if this bug still exists.

Maybe v1.3 or later fixes The Bug (hard to tell, it is so intermittent), but how about John's point that there is no way to back up bookmarks? Surely, we all need that! (or is there a way?)

Possible hope for some of the bookmarks problems ... I've been close to giving up on being able to use Mozilla 1.3 due to not being able to import bookmarks from my old system (1.2.1), and have watched for updates on what appears to be a fairly critical bug. My basic problem was that no amount of editing, exporting, importing or file replacing would result in a good bookmarks file. I always wound up with the default, with possibly a dozen or so useless additional links with no labels, but that I recognized as bookmarks I'd saved. I'd noticed previously that a corruption had somehow inserted many blank lines and horizontal rule lines, so in desparation, I finally expenaded every folder on the old system bookmarks file using the manage bookmarks tool, and removed every occurance of these blank lines and extra horizontal rule lines. I can now import this newly edited file into my bookmarks. Perhaps the code that does the checking of the bookmarks file would reveal that it replaces the file with the default if errors are found, or gives up too soon on the file, or doesn't keep the good stuff that it's actually able to import. So could it be html syntax that's confusing something? Seems this code could be a bit more robust, or at minimum, give an indication somehow of where it was in the import or bookmark save process when it looses its head. Worked for me; hope this helps nail this one down. Now if we could only get this dual display/mouse/cursor/selection/high-lighting thing fixed, I'd really be a happy camper! :-)

I've had this happen to me about 4 times now, each time after either a reboot or after I turn on my computer after it's been off a while.

I can confirm this bug still exists in the Mozilla 1.4a Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 version. System crashed and upon the reboot all the bookmarks were wiped. I agree that a good temporary fix to this would to make a backup before any changes are made to the bookmarks.html. this should not be too hard to implements.

Is there a (numbered) bookmarks file in de profile folder, that might contain your bookmarks? On a Win2K system it is in the Documents and Settings folder of the user, in the (normally invisible) folder "Application data/mozilla ... etc". Although after importing you might loose the "Personal Toolbar Functionality"

I've had this happen to me twice. Both times, when Mozilla crashed, no talkback event was gerated, and it forced a hard boot of my system. (Yes, I was staring at BIOS messages) Both occasions, I was closing the only open occurance of Mozilla. Pages had already been loaded, and were not performing any function. Mozilla 1.3 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 On both occasion, i lost all bookmarks. (Made a backup of my bookmarks after the last time this happened) I agree with the above comments, some type of versioning should be implemented. Maybe a .bak file before every write. Good luck with this one. Seems like it's a very persistant bug.

*** Bug 193963 has been marked as a duplicate of this bug. ***

*** Bug 205935 has been marked as a duplicate of this bug. ***

*** Bug 210679 has been marked as a duplicate of this bug. ***

*** Bug 217904 has been marked as a duplicate of this bug. ***

*** Bug 221037 has been marked as a duplicate of this bug. ***

I confirm seeing this bug with different versions on Linux. It happens fairly frequently aftere updating to a new Mozilla nightly. This was the reason why I stopped using nightlies after the last time this happened (only about 3 weeks ago). It happened on both my machines, no crashes lost, just an update to a new version.

I'm experiencing this same bug persistently on OS 10.1.5; every time the browser crashes all bookmarks are wiped out. Sometimes, even on a regular quit the bookmarks were wiped. As others have indicated, the features are great, but if you can't keep your bookmarks it destroys the utility of the browser.

How is this different from bug 131105?

nevermind, I see that bug 131105 is a loss of bookmarks added during that particular session. Is this bug, then, just a component of bug 193749 that deals explicitely with Bookmarks and not preferences or other files?

I'm still seeing lost bookmarks in the "milestone" Mozilla 1.6b of 12-08-03. The release notes mention it and the bug number 221843 for it. Apparently Mac Os 10.1.5 has the problem and Jaguar doesn't. A good reason for updating, if true! Keep a backup bookmark file at all times. The bookmark file comes and goes so you'll want to locate the actual file and keep watch over it. I prefer replacing the blank file with the good file, rather than Importing or setting the bookmarks folder, so I don't have to bother with re-setting the Personal Toolbar Folder. (Manage bookmarks, then look under Views.) For Mac, the bookmarks file is in Users/yourname/Library/Mozilla/Profiles/yourprofile/xxxxxx/bookmarks.html You can "set bookmarks" to another file in another folder; then that file will come and go instead. A crash will often blank out the bookmarks, but not always. Closing a window, but not closing a tab, will often update the bookmark file or make it reappear. (Where are the bookmarks when the file is missing?) http://www.mozilla.org/releases/mozilla1.6b/README.html ///Polly

How is it possible that it is more than a year since I had this bug, many versions ago, and I still have it with mozilla 1.5?? It is truly staggering that this problem is still occurring. The user's bookmarks are easily the most important piece of information that mozilla has on the user, and yet it seems that the devs don't care about this enough to ensure that a massive file with hundreds of bookmarks doesn't get overwritten by a tiny default file when there have been no user changes to the bookmarks!! This is a trivial thing to implement. What is the problem? Why does the problem persist? Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031118 Don't get me wrong. I love open-source and free software. Linux has been my primary OS for two years or so, and I've used Mozilla since way before 1.0. I've recommended Mozilla to countless people, and yet, I am so disappointed at how long people have been having their precious bookmarks deleted that I am considering abandoning mozilla. Konqueror has _never_ deleted my bookmarks. Opera has _never_ deleted my bookmarks. When I used windows, IE _never_ deleted my bookmarks, netscape _never_ deleted my bookmarks. What is it so difficult to get this arguably most important of all tasks correct?? Please, I would really like an answer. I am a programmer myself, and I can think of more than one way to easily prevent this, and others have made easy-to-implement suggestions too. Mozilla has supposedly been stable for many releases now. However, I would argue that a browser that cannot even prevent faulty overwriting of the most important user file on the system is not stable. It would be preferable for most users if *every other mozilla file* on the whole system were deleted and they had to reinstall from scratch, but still had their bookmarks. I've taken to backing up my bookmarks daily, but do you think I can get my grandma to do that? More importantly, what does it say about Mozilla that the only solution to this *very old* problem is apparently backing up the files in anticipation of the next time that mozilla **** up and deletes it again? My apologies in advance for this screed, but I am dumbfounded at the number of times this has happened to me, and how long it has been since I first saw the bug and that it still occurs, with apparently no solution in sight. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031118 One last thing: what you moz devs say if Moz had never had a problem with this, and an IE user told you that IE randomly, for no reason at all, would overwrite years of accumulated bookmarks with a default file? You know very well you would tell them IE is for that reason a worthless pos if it can't get fundamental task of saving a bookmarks file correct.

Maybe this wil help sort out the issue on MacOS X. I was using MacOS X 10.1.5 up to mid November when I would regularly experience this bug. Since I updated to MacOS 10.3 I have not encountered this bug once! I believe this bug only effects Mac systems running 10.1.5. Maybe the best way to solve this issue for the Mac is to close the bug as "won't fix" since the way to solve this bug is to update to 10.3. (BTW more and more software packages can no longer run on 10.1.5) MacOS X 10.3 is in its plumbing is so different than 10.1.5 that maybe it is only possible to fully support 10.2+ unless a seperate compile is produced targeting 10.1.5 (compiled with an older version of GCC running on 10.1.5. There is a point when backward compatibility (i.e. Mozilla running on 10.1.5) is no longer possible. Safari, Apple's browser is unable to run on 10.1.5. If Apple did support Safari on 10.1.5 very likely they would either safari would suffer with many bugs or Apple would have to write a seperate 10.1.5 version. If you *cannot* live with this bug the hard reality is that you may have to upgrade your OS for the bug to go away. (Slightly off topic: before upgrading from 10.1.5 to 10.3 there were many minor bugs I encountered (although not that often), such as some HTML/CCS rendering bugs causing a page to be unreadable with text columns printed on top of on another. After upgrading to 10.3 these bugs are not there. Another reason to upgrade to 10.3 and possibly make the hard decision that Mozilla maybe (because of the differences between 10.1.5 and 10.2+ (incl. 10.3.2) that it is not possible to fully support 10.1.5. I hope this is not the case, but maybe this is the harsh reality and must be faced sooner or later.)

Gene - well said. That this bug has not been top priority since verification is astonishing. sPh

Is this bug still different from bug 193749? I mean for some of the dupes here the loss was after a crash. Some problems could be Mac-only, see Bug 221037.

About the possibility of being Mac related: I have not experienced this bug since I upgraded from MacOS X 10.1.5 to 10.3. I never tested with 10.2. Several Mac bugs have hinted at the possibility that builds compiled with gcc on using MacOS 10.3 may have compatibility issues with earlier versions of the MacOS, paticularly 10.1.5. Apparently the OS has enough differences between 10.1.5 and 10.2 that Apple stated when it launched its browser Safari that it would not be supported on 10.1.5. Some may not like what I want to suggest. Are there some bugs effecting Mozilla when run on MacOS X 10.1.5 which cannot be fixed. Are the differences between 10.1.5 and 10.2+ (incl. 10.3.2) so great that Mozilla cannot fully support 10.1.5? I don't know. I throw this question out to those more knowledgable than myself: can Mozilla continue to support MacOS 10.1.5?

This bug is practically worthless. For all the dupes and the "me too" comments, there isn't a single comment among the nearly 60 here that gives clear reproducible steps. There are certainly at least 3, maybe as many as 5 or 6 bugs that have been reported or duped here -- two or three of which have already been fixed. Every bookmarks loss is not the same! If you were on Mac 10.1 when you experienced a loss of all bookmarks (not a reverting back to defaults, rather a completely empty bookmarks folder) then you were experiencing bug 221843. If you lost your bookmarks and other profile data because of a full disk, your problem was probably bug 192425. If you were running PC-cillin or some other anti-virus program and you lost your bookmarks along with _all_ of your profile, then you were probably experiencing bug 170539. If you lost all of your data after an abnormal _OS_ shutdown (power failure, etc.) then you were probably experiencing bug 193749. This bug is also a mess and has several bugs reported or duped into one so some of the conditions that people have reported to trigger this bug no longer trigger it. If your system died while you were in the process of editing bookmarks and the file was truncated when you returned, your problem was probably bug 227331. If you just lost the bookmarks created during the most recent browser session, then you were seeing bug 131105. So this bug is pretty worthless. If your issue isn't one of those problems, and you can reproduce the problem well enough to describe steps that would allow a developer to reproduce the problem, please file a new bug report with your build ID and clear steps to reproduce the problem. Feel free to note the new bug in the comments here so that anyone else tracking these various issues can follow up. I read through all of the duplicates and I didn't see any bugs that were reported against a recent build with clear steps to reproduce. If your bug was duped against this one improperly and you have included clear steps to reproduce, please reopen your bug and note that reopening here. Thanks.

The same thing happens to me; four times now.I use XP Pro with the latesst service pack. It did not happen until the last month. I have been using Mozilla for about 6 months.