[FIX]crash causes loss of bookmarks added during current session

VERIFIED FIXED in mozilla1.6beta


18 years ago
15 years ago


(Reporter: webbi, Assigned: caillon)



Dependency tree / graph
Bug Flags:
blocking1.3 -
blocking1.4a -
blocking1.4b -
blocking1.6b -
blocking1.6 +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt3])


(1 attachment, 1 obsolete attachment)



18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+)
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.

Comment 1

18 years ago

*** This bug has been marked as a duplicate of 98476 ***
Closed: 18 years ago
Resolution: --- → DUPLICATE

Comment 2

18 years ago
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. 

Comment 3

18 years ago
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.
Keywords: dataloss
Resolution: DUPLICATE → ---

Comment 4

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

Comment 5

18 years ago
According to bug Bug 43502, the bookmarks are supposed to be written after every

Confirming based on duplicate.
Ever confirmed: true

Comment 6

18 years ago
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? 

Comment 7

18 years ago
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.


18 years ago
Keywords: mozilla1.0

Comment 8

18 years ago
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.

Comment 9

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

Comment 10

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

Comment 11

17 years ago
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?

Comment 12

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

Comment 13

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

Comment 14

17 years ago
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...

Comment 15

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

Comment 16

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


17 years ago
OS: Windows NT → All

Comment 17

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

Comment 18

17 years ago
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.

Comment 19

17 years ago
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).  :-)

Comment 21

17 years ago
*** 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. 

Comment 23

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

Comment 24

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

Comment 25

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

Comment 26

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

Comment 27

17 years ago
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?

Comment 28

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

Comment 29

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

Comment 30

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

Comment 31

17 years ago
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... !

Comment 32

17 years ago
This happens on Mozilla 1.2 running on W2K, as well as the Mach-O builds of
Mozilla for Mac OS X.
Flags: blocking1.3b+


17 years ago
Flags: blocking1.3b+

Comment 33

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

Comment 34

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


17 years ago

Comment 35

17 years ago
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.
Flags: blocking1.3?

Comment 36

17 years ago
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.
Flags: blocking1.4a+
Flags: blocking1.3?
Flags: blocking1.3-

Comment 38

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

Comment 39

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

Comment 40

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

Comment 41

17 years ago
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?

Comment 42

17 years ago
> 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?

Comment 43

17 years ago
Benjamin, could 
be of any help for you? This is called by Shutdown() when a navigator window is

Stewart, for me Bookmarks _are_ saved after when the manager (1.3, Win2k).

Comment 44

17 years ago
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

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)

Comment 45

17 years ago
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.

Comment 46

17 years ago
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.


17 years ago
Flags: blocking1.4a+ → blocking1.4a-


16 years ago
Flags: blocking1.4b?
Keywords: nsbeta1

Comment 47

16 years ago
Updating qa contact to petersen@netscape.com
QA Contact: claudius → petersen
navtriage: nsbeta1+/adt3

Over to Jan.
Assignee: ben → varga
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt3]


16 years ago
Priority: -- → P3
Target Milestone: --- → mozilla1.4beta


16 years ago

Comment 49

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


16 years ago
Flags: blocking1.4b? → blocking1.4b-


16 years ago


16 years ago
No longer blocks: profile-corrupt


16 years ago
Flags: blocking1.4?

Comment 50

16 years ago
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.
Flags: blocking1.4?

Comment 53

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

Comment 54

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


16 years ago
Blocks: 19454


16 years ago
No longer blocks: 19454

Comment 55

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

Comment 56

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


16 years ago
Flags: blocking1.6b?

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.


Comment 58

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

Comment 59

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


16 years ago
Flags: blocking1.6b? → blocking1.6b+
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.
Assignee: varga → caillon
Priority: P3 → P1
Target Milestone: mozilla1.4beta → mozilla1.6beta
Posted patch Something like this (obsolete) — Splinter Review
I haven't tested this yet, but it should do the trick.
Posted patch Better patchSplinter Review
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.
Attachment #136868 - Attachment is obsolete: true
Summary: crash causes loss of bookmarks added during current session → [FIX]crash causes loss of bookmarks added during current session
Attachment #136884 - Flags: review?(neil.parkwaycc.co.uk)
Ben, can you take a look at this and help us drive it into 1.6 final?
Flags: blocking1.6b-
Flags: blocking1.6b+
Flags: blocking1.6+
Comment on attachment 136884 [details] [diff] [review]
Better patch

Attachment #136884 - Flags: superreview+
Comment on attachment 136884 [details] [diff] [review]
Better patch

Marking Ben's review from comment 64.
Attachment #136884 - Flags: review?(neil.parkwaycc.co.uk) → review+
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?
Attachment #136884 - Flags: approval1.6b?
Attachment #136884 - Flags: approval1.6b? → approval1.6b+
Fix checked in.
Closed: 18 years ago16 years ago
Resolution: --- → FIXED

Comment 69

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

Comment 71

15 years ago
*** Bug 247472 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.