From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/20020314 BuildID: 2002031403 Bookmarks added during the current session are lost if Mozilla crashes. Reproducible: Always Steps to Reproduce: 1. Bookmark a site with Bookmarks -> Add Bookmark 2. Crash Mozilla [I used the testcase for Bug 131008) Actual Results: Upon restarting Mozilla, the bookmark added in step 1 will not be in the bookmarks list. Expected Results: Upon restarting Mozilla, the bookmark added in step 1 is in the bookmarks list. Marking Critical because data loss is involved.

*** This bug has been marked as a duplicate of 98476 ***

This doesn't seem to be a dupe, unless I'm fundamentally misunderstanding Bug 98476. That bug discusses loss of bookmarks.html, but this isn't losing the whole file -- the file only loses those bookmarks added during the current session. This *might* be an unintentional side effect of a fix for 98476, if so this dataloss needs to be attached to that bug.

Reopening. This might be a dupe of some other bug, but not the generic profile corruption bug. The problem here is that bookmarks.html is not written to disc with every change. Maybe that's needed, or maybe that's unavoidable, but that's what this bug is about.

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

According to bug Bug 43502, the bookmarks are supposed to be written after every change. Confirming based on duplicate.

Reporter could you please test this again? Add a bookmark. Then, wait 30-60 seconds. Then, crash the browser as per one of the known test cases. Is the bookmark written then?

I can reproduce on the latest nightly, 2002031403, with a 2-minute wait between adding the bookmark and crashing the browser. The added bookmark still isn't there when the browser is restarted.

I can confirm this bug. Everytime Mozilla is forcefully closed or some other failure brings down the system all the bookmarks created in that session are lost. This showd up on build 2002031008. The system was hung after many hours of inactivity from Mozilla and several bookmarks and history information was lost. All relevant to the session that was killed by the system hang. I lose bookmarks on this build every time Mozilla is crashed. Usually when I forget to close a Mozilla window before logging out of KDE. The bookmarks file is definately not getting synced at each bookmark.

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

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

Is anyone looking at this? I just noticed that mozilla 1.1a received "redundant backup of preferences files." This bug has keyword mozilla1.0. When is it getting it's 15 mins of fame?

Is anyone seeing this on Linux or the Mac or some other system besides Windows?

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

I can reproduce this on Linux. A hard crash of mozilla isn't even required. If I exit mozilla using the Quit menu option, then my bookmarks are saved, if I send the mozilla process a TERM signal (killall mozilla-bin), I lose the bookmarks, so in my case everytime I exit my window manager I end up losing my bookmarks since I usually don't close mozilla first...

fixed with the fix for bug 86501? (checked in on trunk June 26th)

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

I can reproduce this on Windows ME with trunk build 2002070504.

FYI: The problem I was seeing on Linux is still there with build 2002072204. - Start mozilla, bookmark a site, ctl-c mozilla or 'killall mozilla-bin' it and the bookmark is lost.

This bug is reproducible on mozilla1.0 on Win98. Bookmarks added as long as 5-10 minutes in the past are lost if Mozilla or the system crashes. Is there any reason not to have the bookmark file saved on every modification? (I'm willing to do coding work if need, 'cept I've never hacked on moz before and would need a fair amount of "getting started" help. Pointers for newbies?)

I've experienced this problem (or a very similar problem) with current and past versions of Mozilla (and Netscape). I'm currently using the 1.1 beta 2002072104. My work-around is, when adding a bookmark, to immediately open my bookmarks (control-b), then close it (which forces a save of the file, it seems). Anyone know if these assumptions are correct? Actually, I stumbled on this bug because I was searching for a problem where using the above method has started to cause crashes (since my bookmarks file has grown large)......not sure if this should be included here (probably not). :-)

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

I can confirm this is still a problem as of build #2002090508. Create a bookmark, crash mozilla, restart mozilla, newly created bookmarks are all gone.

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

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

This is indeed a VERY annoying problem. I can't believe it still isn't fixed

Sorry, got a little triggerhappy :) I can confirm this bug on linux (Mozilla Debian Package 1.1-1)

I've been having more crashes, and yet seem to be loosing new bookmarks less often (or possibly not at all) in trunk build 2002091908 on linux. Maybe someone should check if the recent trunk builds have improved the situation?

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

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

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

Similar problem here except that I lost all my bookmarks... Mozilla 1.1 crashed, and as it was asking to send a bug report electricity went down. When I restarted my computer and Mozilla all bookmarks were gone, and the sidebar that I never used was on. When I checked the bookmarks file it was 1 k instead of 167 k. Thanks for looking into this. Now I can go crying... !

This happens on Mozilla 1.2 running on W2K, as well as the Mach-O builds of Mozilla for Mac OS X.

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

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

Confirmed on Win98SE for every build up to 022603. I'm sorry but I can't believe Mozilla is neglecting this bug. I'll search for an analogous cookie loss bug, which is equally annoying.

Sorry for the spam but confirmed on WinXP w. latest build, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030228. The cookie prob seems to have disappeared so that's good. I do think this should block 1.3 (late as it is). It's simply too inconvenient for the avg user.

Not going to happen for 1.3. Hopefully 1.4alpha.

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

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

this bug is a waste of my time to have observed for a year

Jan, this looks like an easy fix that I could probably accomplish. I know that bookmarks are saved (flushed) when the bookmark manager dialog is closed, but I couldn't find the actual JS that accomplishes this. Can you point me in the right direction?

> I know that bookmarks are saved (flushed) when the bookmark manager > dialog is closed It doesn't on mine! See bug 159642. What version/platform do you have?

Benjamin, could http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.js#653 be of any help for you? This is called by Shutdown() when a navigator window is closed. Stewart, for me Bookmarks _are_ saved after when the manager (1.3, Win2k).

Er... "is closed." is missing in my previous comment. Please note again (already mentioned) bug 43502 comment 4 where is said: "Bookmark changes are coalesced together and written out within approximately 10 to 15 seconds after operation completion." - which is about the best way to do it (think about moving large numbers of bookmarks: flushing for every change could hurt performance badly there. BUT: in bookmark manager this _does_ work! Do a change and the bookmarks file is written within seconds (this is before _and_ after the recent bookmarks branch landing). This also worked/works with modifications of bookmarks in the personal toolbar. Adding bookmarks there only works after the bookmarks branch landing. Modifications and drag and drop in the bookmarks sidebar also saves the bookmarks. The four places where this still does not work now are: - the "Add..." button in the bookmarks sidebar - the Bookmarks menu: "Bookmarks" - "Bookmark This Page" - the Bookmarks menu: "Bookmarks" - "File Bookmark..." - the Bookmarks menu: "Bookmarks" - "Bookmark This Group of Tabs..." (Dragging to the Bookmarks menu (which now works) _does_ save the bookmarks)

Whom is your last comment actually aimed at? I am telling you that in my version (1.3beta, Mac OS X) this _doesn't_ work. And I have just tried doing it with the sidebar. Created some new folders, moved bookmarks into them, exit Mozilla and restarted. Same result - all changes lost.

Stewart, as I mentioned several times, a few days ago the bookmark branch has landed on the trunk with a lot of rewriting and architectural changes (see bug 160019 and bug 196756). For testing the new bookmarks system you have at least to use a current nightly or wait for the upcoming Mozilla 1.4a. If you still have a problem in 1.3beta that just doesn't matter anymore; 1.3b is history, the problem (at least as described in your last comment) fixed. My last comment was partly a general summation of where we are now, partly aimed at Benjamin (or whoever is going to fix this) to point out which places still need to be fixed. If you find other places where the bookmarks are not saved after modification, you are invited to add a comment. But please only if reproducible in a *current* Mozilla trunk build.

Updating qa contact to petersen@netscape.com

navtriage: nsbeta1+/adt3 Over to Jan.

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

http://bugzilla.mozilla.org/attachment.cgi?id=64787&action=view is a crash test case. Wait a few secs or click in form to crash browser. This boomark bug itself seems to have been fixed. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030523 Mozilla Firebird/0.6

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

mozilla1.4 shipped. unsetting blocking1.4 request.

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

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

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

Nothing happening here for the past 8 months. This is still present in v1.5 release. Any chance for 1.6?

Hi, I suggest to add a feature to Mozilla / Firebird that allows to create backups of files such as bookmarks.html, Personal toolbar, mail prefs, news prefs, etc. How about adding a menu entry to the "Edit / Preferences..." menu underneath the "Navigator" branch called "Settings backup"? This should contain tick boxes of what somebody wants to backup, to where and how often (time interval) this should happen. Also a restore feature should be introduced with a selection option what and which backup should be restored. This may solve some of the issues where an OS freezes or crashes unrecoverably. --Christian

Christian: what you just suggested (in at least two different bug reports!) is bug 22689.

There seem to be quite a few on this: bug 218636 (FB), bug 226720.

Taking bug. We are all set to do this, really. All the mechanisms are in place. We have a timer set up to lazily write out our bookmarks file is 'dirty', and a nice function which does so. The problem is, we never mark bookmarks as 'dirty' so nothing ever happens. I should have a patch soon.

I haven't tested this yet, but it should do the trick.

So not everything has the power to tell us we're dirty. Instead, those callers manually flush us, so we can't check the dirty bit in Flush() itself. I moved that check back to the timer callback. This should work a little better. I've tested it and it appears to work nicely.

Ben, can you take a look at this and help us drive it into 1.6 final?

Comment on attachment 136884 [details] [diff] [review] Better patch r=ben@mozilla.org

Comment on attachment 136884 [details] [diff] [review] Better patch sr=bzbarsky

Comment on attachment 136884 [details] [diff] [review] Better patch Marking Ben's review from comment 64.

Comment on attachment 136884 [details] [diff] [review] Better patch This should go a long way to help the problem. It marks bookmarks as dirty when we touch them internally so we can flush them when our timer is called. I wonder if we want this for any branches as well?

Fix checked in.

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

verified.

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