User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 Recently, I have witnessed too many cases of users losing their bookmarks (on various machines and with several versions of Mozilla). Here's a list of all related bugs that I had managed to find: Bug 159642 - Lost bookmarks while organizing into folders Bug 163899 - Empty bookmarks written, if some error in bookmarks file Bug 193749 - bookmarks and personal preferences are lost after system crash due to power failure Bug 164244 - Bookmarks become intermittently corrupted, revert to the defaults. Bug 109377 - Mozilla fails to detect read-only status of critical files (bookmarks.html) Bug 190136 - Full hard drive causes Mozilla to lose its prefs and bookmarks Bug 52205 - Bookmarks.html is created read-only - bookmarks aren't saved Bug 131105 - crash causes loss of bookmarks added during current session Bug 193749 - bookmarks and personal preferences are lost after system crash due to power failure Unconfirmed bugs: Bug 200217 - Browser Window insisted I upgrade to version 1.3 from 1.3a. Upon completion all bookmarks, mail , and mail settings are gone. Bug 199050 - bookmarks lost on restart Bug 188401 - newly added bookmarks will not save (ie. they are not there when browser is reopened.) Bug 193963 - large bookmarks.html file wiped out after crash Bug 201027 - bookmarks disappeared without any prior problem over the weekend Bug 149022 - Dragging proxy icon onto bookmarks icon causes bookmark to diappear. Bug 166358 - Painfully slow file saves and loss of bookmarks when Netscape 7.0 is present Just fixed for 1.3.1: Bug 196834 - all bookmarks lost when using "browser.bookmarks.file" pref and switching profile As Andrew Hagen (xah@myrealbox.com) suggested to me in email, this bug should include any/all bookmarks bugs from Bug 123929. It should then block 123929. Prog. Reproducible: Sometimes Steps to Reproduce:

Confirming.

I added some other ones, too.

Bug 190136 was duped to bug 192425. Replacing in depends.

I'm not sure, but I think bug 159642 was fixed when pch's robust bookmark handling landed.

Bug 44507 has nothing to do with bookmarks. Removing depend. If this was a typo, please check which bug you intended to add.

8 users here are experiencing the 'vanishing bookmarks.html' consistantly and reproducibly. OS: MacOS X 10.2.[3|5|6] (same behaviour on all, currently using .6) Hardware: G4 Dual 1.25GHz w/1.75G RAM, PowerBook 12" w/867M RAM (several of each) Third-party UI shareware hacks: NONE Mozilla Version: The G4 workstations have home directories and other volumes NFS-mounted. The PowerBooks have local (HFS+) home directories. I've been testing Conrad's patches in bug 196487 since April, so I build & patch almost nightly out of CVS so that Mozilla works on NFS. My .mozconfig for building is as follows: ac_add_options --enable-ldap-experimental ac_add_options --enable-prebinding ac_add_options --enable-crypto ac_add_options --enable-extensions=all ac_add_options --disable-tests ac_add_options --disable-debug ac_add_options --enable-optimize=-O2 ac_add_options --without-system-nspr ac_add_options --without-system-zlib ac_add_options --without-system-jpeg ac_add_options --without-system-png ac_add_options --without-system-mng ac_add_options --disable-shared ac_add_options --enable-static Steps to reproduce with the profile on an NFS home directory: 1. Launch Mozilla & Check bookmarks menu - it's empty. 2. Look in <whatever>.slt - no bookmarks.html 3. Add a bookmark. 4. Quit Mozilla. 5. Look in <whatever>.slt - no bookmarks.html OR 1. Launch - no bookmarks.html 2. Add a bookmark - no bookmarks.html 3. Close Navigator window without quitting Mozilla - bookmarks.html appears 4. Open Navigator window - bookmarks.html DISAPPEARS 5. Close Navigator window - bookmarks.html appears again 6. Quit Mozilla - bookmarks.html DISAPPEARS (again) ...and so on. In some cases, the bookmarks.html file may not be 'eaten' on close for one or two times, but within 5 sequential launch/quit/launch/quit/etc. it WILL be eaten. Steps to reproduce with the profile on an HFS+ home directory: Unable to provoke or reproduce in this configuration (same machine) Also, Personal Toolbar Folder functionality is lost when a new bookmarks.html is created or a backup bookmarks.html file is used. Even if the folder is created and named appropriately, it doesn't function as intended. There is no option in any menu (right-click or otherwise) to 'set' a folder as the PT. I believe bookmarks dataloss should block 1.4. Thanks for your help. I'm willing to test any patches, please contact me directly for that.

This is still consistant and repeatable as of the 19 June RC_3 build. Please, please consider this critical enough to block 1.4 (the new icons are nice, but this is serious...) It only occurs with profiles on NFS home directories. I'm willing to work with you to test any patches at my site. Thanks,

The following bugs appear to be related, but are not listed in the 'depends' above: 203583 204581 205053 205200 205231 205591 205664 209975 210661 210856 211050 ...and there doesn't seem to be any activity on any of them. I can confirm that it's happened with CVS since at least 9 May, RC[1|2|3] and 1.4-final. I have at least 8 users here experiencing the problem.

metabugs don't block releases.

Happens quite randomly over here, 20030425

I believe the bug 221037 "Dataloss:Bookmarks will sometimes (but not always) disappear when Mozilla is launched." should be included in this meta bug.

Anybody can add dependencies. But since nobody else can seem to be bothered, I'm going to add the ones that people seem to be talking about but not adding to the list: Bug 203583 - bookmarks.html suddenly has zero size Bug 204581 - lost bookmarks. system did not crash. Bug 205053 - Bookmarks lost when installing Mozilla 1.4b Bug 205200 - When installing Mozilla 1.4b, all my bookmarks were lost. Never saw this with other Mozilla-install's! Bug 205231 - Bookmarks lost when I upgraded to 1.31 Bug 205591 - Upon upgrading to this build, all my bookmarks were deleted, except for one small subset of a personal directory entry. Bug 209975 - mozilla1.4 rc2 deleted my bookmarks! Bug 210661 - I've been using Mozilla mail for weeks. TodayI had to set up my mail account, lost all existing mail , lost all bookmarksBug 210856 - Data loss: Bookmarks are missing! Bug 211050 - After updating all my bookmarks were erased Bug 221037 - Dataloss:Bookmarks will sometimes (but not always) disappear when Mozilla is launched. Not sure how many of the various "bookmark file updated OK, but disappeared out of the blue on restart" and "bookmarks lost when I upgrade" bugs should count as dupes of each other.... And by the way, although comment 8 mentions it, bug 205664 has nothing to do with bookmark dataloss AFAICS.

Adding a 'me too' to the pile. Using MacOS 10.1.5 and Mozilla 1.5 Release.

Bug 223384 - Bookmarks file overwriten when running Mozilla 1.5 for the first time. Yet another case of bookmarks lost on upgrade. We have seven now: - Linux - bug 205053, bug 205200, bug 209975, bug 223384 - Windows - bug 205231, bug 205591, bug 211050 Not sure if some of these should be dupes....

A BRUTE FORCE APPROACH: The problem of losing all bookmarks has been around and unsolved for a long time (I didn't know about it until it happened to me with 1.3, and I haven't used Mozilla since). Since it is obviously difficult to fix (or reproduce),I wish someone would at least code a repair routine for when it happens. Possibilities: Simplest: Automatically maintain a running backup of the bookmarks file (perhaps even two generations of it), and in an FAQ/Help file, instruct the user where to go to retrieve that backup if he discovers that his bookmarks have disappeared. Better: Include a "Restore lost bookmarks" item in the Bookmarks menu, which will reconstruct the bookmark menu from an automatically maintained backup (after presenting an explanation dialog). Better still: Have the program check to see if it is displaying the default Bookmarks menu, and if it is, and there is a backup file indicating that there used to be user bookmarks there, automatically rebuild the menu. In all cases, it would be best if the backup file were copied/updated after every change to the "real" file (whether add, remove, move, or rename), but for now, even a backup after each add function (or after every so many minutes) would go a long way, IMO, releasing a non-alpha program with a known bug that causes the user to irretrievably lose data is unacceptable. Creating a way to un-do the damage (until such time as the underlying bug is actually found, if ever) I think should be a very high priority, and is necessary to make the product "fit for public consumption".

Good idea, I reckon. Feel free to file a new bug report to suggest this. But a few more notes I'll say here before I forget.... I reckon the "better still" is particularly important. Otherwise someone might start Mozilla, go to a site and bookmark it by pressing Ctrl+D/Cmd+D, remaining unaware that all his/her bookmarks from the last session have vanished. Then the backup would be overwritten again. I'm also inclined that there should be a backup of the bookmarks at the beginning of the session, not just after each operation.

Adding 227331 - Abnormal shutdown truncates (large) bookmarks.html

Hi, I have lost my bookmarks several times as well. I also lost history and cookies... It happens when mozilla is running and the computer crashes. I am under windows2000 professional and mozilla is 1.4 or 1.5. I usually don't swich of the computer, it seems the computer crashes when mozilla has been running for a long time or when I have been very active on the net. I shall try to close mozilla on a regular base to see if that change anything. Florent

Removing all the bugs that are marked DUPLICATE from the depend list. These were bug 203583, bug 205200, bug 205231, bug 209975, bug 211050, bug 221037, bug 222339, bug 223384

The error always still exists in Mozilla 1.6.

All of my bookmarks simply disappeared without any reason. I can't even get the bookmark toolbar to function correctly.

John, to get help in resolving this problem try http://www.mozilla.org/support#community Prog.

I tried posting previously the following, but it seems not to have showed up. -------------------------------------------------------------- I still maintain, and have complained several times in the newsgroups, that moz bookmark function has multiple problems that go *backward* from NS 4.8. In one of these messages [news://news.mozilla.org:119/c1dfup$fgl2@ripley.netscape.com], I indicated the following bookmark-specific items: "Other items that went backward from NS 4.x include removal of 'insert separator' from the right-click context menu in bookmarks manager, the scrolling format of bookmarks in a large file, vs. the multi-column wide view [*much* superior, IMO],". In a later post, someone else wrote: "I also have accumulated a large bookmarks file, and really miss Netscape 4's ability to search (find) withIN the bookmarks window -- IOW just advance to and select the (next) matching bookmark within the (context of all the) other bookmarks. " I also agree with this assessment. Finally, in a yet later article [news://news.mozilla.org:119/c2au3h$ga23@ripley.netscape.com] I indicated some additional problems: "1. Even for the toolbar folders into which I can drag/drop links, the list will not scroll, so I am limited to only the range that comes up by default. Also, what I consider the backward movement to the scrolling bookmarks [vs. multi-column format] also impacts this negatively. 2. I cannot drag/drop links into the pulldown-menu bookmarks list at all. " These last 2 issue, though, seemingly are sporadic; occasionally [but not usually] they seem to work. FWIW, moz 1.6/win2k[fully patched]. Sorry if these issues duplicate, but my initial search did not show them on here. I resisted going bugzilla, but finally got fed up and had to provide $.02. Thanks.

That complaint does not seem relevant to this bug.

(In reply to comment #24) > That complaint does not seem relevant to this bug. I disagree. The bottom line problem is that the bookmarks file is not writing itself correctly. This is the most closely related bug I could find; if you start shunting off this type of report as not related, then you open yourself to tons of new bug reports that, IMO, seem rather likely to have a common problem with this one.

(In reply to comment #25) > (In reply to comment #24) > > That complaint does not seem relevant to this bug. > > I disagree. []eports that, IMO, seem rather likely to have a common problem with this one. > > I should modify my reply; yes, what I posted here is more marginal to this particular issue. Sorry for adding any confusion. More useful would have been to reference *this* post: news://news.mozilla.org:119/c75tqi$n591@ripley.netscape.com and my follow up: news://news.mozilla.org:119/c7ohh6$icn1@ripley.netscape.com Bottom line I *intended* to convey: bookmarks file is not saving itself correctly, leading to losses of new URLs whether closed normally or crashed. Sorry for adding confusion.

Another way to lose your bookmarks If you run mozilla via sudo (for example when installing system-wide extensions like multizilla), mozilla sets the ownership of the bookmarks.html file to root:root. The next time you start mozilla as the same user who ran 'sudo', mozilla tries to open bookmarks.html, but because it's owned by root, the file is not readable. Instead the file is truncated to zero bytes (because the normal user has write access to the directory - can write and delete and therefore truncate but cannot read this file) and you lose all your bookmarks. If you run mozilla via sudo, you *must* change the ownership of bookmarks.html back (or make sure it has o=rw permissions) before running mozilla again as your normal user. I think the fact that mozilla seems to place the bookmarks.html file in such jeopardy is bad.

David Antliff, the problem you've described in comment #27 warrants a separate bug report. Please open a new bug and mark it as blocking this one. Prog.

(In reply to comment #28) > David Antliff, the problem you've described in comment #27 warrants a separate > bug report. Please open a new bug and mark it as blocking this one. I performed a search and found bugs 212447 and 205053 that already cover this, however for older versions of mozilla. The bug is still present in 1.6 (linux).

Well, bug 212447 is a dupe, and bug 205053 is already listed here, so the bug reporting is taken care of. A bug report applies from the version in which it is reported to the version in which it is resolved. If each bug were re-filed for every version, the database would grow beyond usability.

Clearing the 1.7+ blocker flag set by "j" a.k.a. 0py4obm02@sneakemail.com. J: Only Mozilla DRIVERS can set blocking flags. You can REQUEST that a driver considers this bug for blocking by setting it to "?".

In this case, there no point to request blocking at all, as "metabugs don't block releases." (see comment #9). Prog.

(In reply to comment #31) > Clearing the 1.7+ blocker flag set by "j" a.k.a. 0py4obm02@sneakemail.com. > > J: Only Mozilla DRIVERS can set blocking flags. You can REQUEST that a driver > considers this bug for blocking by setting it to "?". OK, sorry, that was my intention.

(In reply to comment #32) > In this case, there no point to request blocking at all, as "metabugs don't > block releases." (see comment #9). > > Prog. That's real helpful, repeating a previous, non-elaborative comment. Those of us without the time to help develop are trying to help with comments, yet you seem to trap these responses in a permanent loop. OK, then: 1) How about explain what the **** is a 'metabug', and why this is one? Search of mozilla site gave 3 non-explanatory references. Essentially the same results from >15 online references. 2) WHY NOT??? This is simply a CRITICAL problem, and everything I see suggests you continue trying to AVOID it rather than ADDRESS it!!!

To simplify the concept of metabugs, think about them as a folder in your bookmarks. These bugs are just pointers to help track other ("real") bugs. Just follow the "depends" list above, and vote for the bugs you feel are most important. As for the Blocking flag, there's really no use in messing with it, unless a bug has a patch. This bug doesn't (and won't naturally), which is another fine reason to leave that flag alone. I suggest that you read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html Prog.

How the hell can this *all-OS* bug 'depend' on a linux-specific bug [251456]???

It's simple. For a bug to be fixed on all OSs, it must be fixed on Linux, and for it to be fixed on Linux, the Linux-specific bug on which it depends must be fixed. OK, so this is a tracker. But a similar logic applies. A tracker cannot be singled out as applying to a single operating system, unless its purpose is to track failings of some kind specific to one OS (e.g. bug 12985). And so the OS is specified as All. This doesn't mean that it's exclusively to track cross-platform bugs, simply that it can track bugs regardless of the OS on which they occur.

(In reply to comment #37) > It's simple. For a bug to be fixed on all OSs, it must be fixed on Linux, and > for it to be fixed on Linux, the Linux-specific bug on which it depends must be > fixed.[] OK, gotcha. Thanks.

Lack of clarity on Profile Manager, and the ill-designed manner through which Profile Manager is accessible, have teamed to kill my bookmarks. The profile manager is accessible through "firefox.exe -p". However, it won't work if any FireFox window is open. the "-p" is ignored. The most acessible way to run that command ("firefox.exe -p") is to alter the QuickLaunch (or desktop) shortcut. So I ended up with "-p" on my QuickLaunch shortcut. Now the Profile Manager opened each time I launched afresh FireFox.This wan't obviuos because it only shows when launching a fresh copy while no other window is opened. What's worse: What seems to be an action of choosing a profile is actually Creating a new profile: so my bookmarks were erased time after time. True, all this would not have happened had I been more cautious or less tired. Still I think this is a bad design: The profile manager must be accessible in a more sensible way, and it's interface more clear.

(In reply to comment #0) Here is another one that I currently have to deal with on a sort of monthly basis: 114824 - Personal toolbar icons are lost when mozilla is killed (or crashes) ...very annoying.

Anyone can add dependencies. But I'm not sure that this one counts - what's the consensus? Should losing the icon images fall under bookmark dataloss?

I've got a computer that's losing bookmarks under Mozilla and Firefox. This is the first time I've experienced this ever. Mozilla 1.8a3 and Firefox 1.0 are both doing similar things. Mozilla won't let bookmarks be created in the personal toolbar, but it hasn't lost the other bookmarks. Firefox has lost all of the bookmarks. We put Firefox on thinking it might solve the problem, but no luck. Other than backinup the bookmarks file periodically is here any suggestion for avoiding the problems or diagnosing what's going on?

1.7.5 has shipped. Moving request to 1.7.6.

jlrodriguez@terra.es, meta bugs don't block releases. More here: https://bugzilla.mozilla.org/show_bug.cgi?id=203343#c35 Prog.

This is in addition to bug#193916 where I lost my mail files and connection to my email provider.

My Bookmarks were cut off, coincidental with the NEW version (with prominent GOOGLE entry box). It COULD have happened also coincident with a system hang/crash (XP Pro up-to-date) - APPEARS to have lost everything after the Bookmark folder I had JUST added a Bookmark to. THAT Bookmark is preserved...the next Folder and all after are gone!

I just had this happen to me two days ago on my Win XP box. Everything was fine when I shut down the machine. Next morning I turn it on and login, suddenly Firefox has no bookmarks and won't remember window formatting. Every time I restart it the window is tall and thin. I was running 1.5 beta 2 and have since uninstalled and reinstalled RC1 and the problem persists.

After the computer crash, the bookmark still has a similar size to the size it had before the crash. However it is unreadable, even by Mozilla.

I am reproducing the bug systematicaly. I have a problem with my graphic card driver, and each time I close firefox with an applet loaded, my computer crashes. Next time I start mozilla, I have no bookmark and my preferences are lost. Looking at the bookmark.html file, it has the same size than the last one, but it can't be opend since it seems to be a binarry file (see attachement). After closing and restarting Mozilla, the bookmark file is valid but empty, its size is <1k Tell me if I can help and give you more data. I have some developper knowledge...

Forgot... I am running mozilla 1.0.7 on windows XP sp2, on an NTFS partition.

This is a tracker. If you want to discuss a specific bug, how about doing so under that bug's page?

All of my bookmarks mysteriously disappeared. Don't know when it happened, but it did.

Mozilla automatically updated to Firefox 10 and bookmarks are gone. Haven't restarted Firefox on other computer for fear of same thing happening when it installs update.

This bug concerns the old bookmarks.html code in XPFE. Both Firefox and SeaMonkey have been using the (new) Places implementation for some time now. Closing this obsolete bug.