User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040429 Firefox/0.8.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040429 Firefox/0.8.0+ It becomes 0Kb, typed urls from dropdown menu are lost and favicons are lost too. This happens about once in a week. Maybe less than a week. Reproducible: Sometimes Steps to Reproduce: 1. 2. 3. Expected Results: History should not disappear.

The history portion is a dup. Favicons is duped in other bugs. One issue per bug report. *** This bug has been marked as a duplicate of 63292 ***

v

since the summary states no crash, re-opening and marking as duplicate of bug 102519.

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

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

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

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

This is not a dupe of bug 102519. This occurs only on firefox and apparently only on builds later than 0.9. See bug 247576 comment 3 and bug 257334 comment 1.

I can confirm that, at least for me, this is somehow related to Remote Desktop in Windows XP. I'd never linked the two events before, but I had been using Firefox 1.0 on this system, without incident since the 9th. I fired up Remote Desktop for the first time since then today... and sure enough, when I reloaded Firefox on this computer after closing my RD session, the History was completely gone.

This is just coincident. Remote desktop connection has nothing to do with this bug. The bug can be reproduced without using remote desktop connection.

Yep, I'm also suffering from same problem, history is cleared without Firefox or Windows crash. History.dat becomes 0kb, but I don't lose favicons. Creating new profile doesn't help. With Moox 1.0 M3 build story is the same. Happens almost every day, at worst several times a day. I believe best run has been about 3 days without losing history.

Update: Same behavior with fresh Windows Server 2003 installation and Firefox 1.0 release. Also tested with latest nightly build (20041221)in XP, and still losing history(:

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

I too am experiencing history file clearing along with loss of typed url's on the dropdown menu. I am using Firefox 1.0 on a Windows 2000 system. This bug is a significant inconvenience. It occurs about 5 or 6 days apart with symptoms identical to what occurs when the history file is manually cleared by executing tools:options:history:clear. I have not yet been able to determine if it only occurs at a specific filesize for history.dat. Note that Netscape 7.x sorted the dropdown url list by recently used status. Firefox does not do this.

OK, the first step was done, and it can be reproduced in a new profile. The next step is to find out exactly what steps need to be executed within the program to erase the history. Firing up some other application, doesn't count. Once those steps are found, then this bug can actually be fixed by a developer. Until then, there isn't enough information to work with.

I'm not seeing this and the first I heard about it was yesterday in one of the NGs despite the fact that this bug has been open 8 months. I found this bug while trying to help the "victim" in the NG. This is a shot in the dark but it is the approach I'd take if I was seeing this. It only seems to affect a very small number of users and only seems to affect Windows. A new profile and even a clean OS install (comment 12) don't cure it so I would be looking for some external influence. In nsGlobalHistory::OpenDB() it tests if the history file exists and, if it does, tries to open it. If either fail it deletes the file (the assumuption being that it is corrupt if it exists) and creates a new one. What AV, or other "protection" s/w are you guys running? I wonder if your AV is opening the file to scan it (being a .dat it would be considered a system file by AV) in such a way that prevents FF from opening it, e.g. locking it and/or opening it read/write rather than read-only. What I would do is modify this bit of code (I roll my own CVS builds) in nsGlobalHistory::OpenDB() line 2510: historyFile->Exists(&exists); if (!exists || NS_FAILED(rv = OpenExistingFile(gMdbFactory, filePath.get()))) { // we couldn't open the file, so it's either corrupt or doesn't exist. // attempt to delete the file, but ignore the error historyFile->Remove(PR_FALSE); rv = OpenNewFile(gMdbFactory, filePath.get()); } to popup a message box (or just write to the console then run FF from the commandline) saying whether it failed because the file didn't exist or couldn't be opened and instead of deleting the file rename it to history.YYYMMDDhhmmss then you could copy it back to history.dat and see if it could be read OK and if it couldn't you could attach it to this bug so it could be analyzed to figure out how it's becoming corrupt. As I said, a shot in the dark, but it's the approach I'd take as with so few people seeing this and the random nature of it means it will be hard to track down - especially if it is an external influence. P.S. Don't be too **** FF over this, there is an almost identical bug in M$ Visual C++ 6!!

Really only affect a small amount of users? Anyway, I'm using Norton Antivirus. Since there is nearly no Antivirus for Linux/Mac, did any Linux/Mac never meet this bug?

> In nsGlobalHistory::OpenDB() it tests if the history file exists > and, if it does, tries to open it. If either fail it deletes the > file (the assumuption being that it is corrupt if it exists) and > creates a new one. Well, I am not really familiar with Firefox' internals, but I would expect that it calls OpenDB() just once at the startup and uses the returned file reference throughout the entire session. Now, however the history is also reset while the application is running. If my assumption is right, I dont think the actual error is located there but somewhere else where some maintenance work is continuously performed. Otherwise it might be very well the right place. > What AV, or other "protection" s/w are you guys running? I wonder if > your AV is opening the file to scan it (being a .dat it would be > considered a system file by AV) in such a way that prevents FF from > opening it, e.g. locking it and/or opening it read/write rather than > read-only. I am not running any kind of such a "protection" at all. I am using a plain XP SP1. > to popup a message box (or just write to the console then run FF > from the commandline) saying whether it failed because the file > didn't exist or couldn't be opened and instead of deleting the file > rename it to history.YYYMMDDhhmmss then you could copy it back to > history.dat and see if it could be read OK and if it couldn't you > could attach it to this bug so it could be analyzed to figure out > how it's becoming corrupt. This would be a good idea.

fwiw, I'm suffering from this bug and I don't have any AV programs running (XP SP1 too) I /think/ I saw this on Linux too, but I am not sure. Last time I tried to pinpoint this bug, I came to conclusion it might be a corrupted history file, at least in some cases. (I'll post more precise comment when I re-check what I think I saw - but that won't happen soon). That doesn't mean it can't be due to "external influence" for some of people. Again, for what it's worth, I started having this problem relatively recently and I'm having another weird problem with Firefox instability under certain circumstances since nearly the same time. This makes me think it might indeed be another program/OS config influence - on my Windows box. It would be nice if someone built with changes proposed in comment 16 to make some progress on the bug. comment 17: apparently there are a lot of people that don't suffer from this problem.

re. comment 17 > Really only affect a small amount of users? I would say so. There's only 10 on the Cc: list, only 4 bugs dup'ing this, it's been open 8 months and I read the n.m.firebird NGs and browse the Mozillazine forums fairly regularly and the first I knew about it was yesterday. Also, I run FF on 3 XP+SP2 machines - 2 running 1.0 d/l from mozilla.org and one my own CVS build and I've never seen it, except when FF crashes. > Since there is nearly no Antivirus for Linux/Mac, > did any Linux/Mac never meet this bug? I also run my own CVS build on FreeBSD; not seen it there either.

(In reply to comment #18) > Well, I am not really familiar with Firefox' internals, but I would > expect that it calls OpenDB() just once at the startup and uses the > returned file reference throughout the entire session. > It gets called in a lot of places, so I doubt it http://lxr.mozilla.org/seamonkey/ident?i=OpenDB

(In reply to comment #19) > It would be nice if someone built with changes proposed in comment 16 to make > some progress on the bug. I've added myself to the Cc: list so if no-one else does it I'll spin a build with those mods and put it on my website.

(In reply to comment #21) > It gets called in a lot of places, so I doubt it > http://lxr.mozilla.org/seamonkey/ident?i=OpenDB Well, as I said, I am not really familiar with its code, so my assumption can be entirely wrong :). Under these circumstances, it might be a simple synchronisation issue, that two threads try to call OpenDB() and because of the first the second fails and deletes the file. Just a guess however.

(In reply to comment #22) > I've added myself to the Cc: list so if no-one else does it I'll spin a build > with those mods and put it on my website. It would be nice, if you could build a version with those modifications. I also have this bug on win xp sp2 with avg free av and kerio personal firewall running Firefox 1.0 It happens in about 2-3 days. As I realised it happens when the history file becomes larger than 1Mb. If I copy back a former history file, it works fine.

I did some research and found that in my last case the following entry in history.dat caused firefox to erase the whole history: @$${307{@ <(4A5B8=1107339690765625)(4A5B9=237)> {1:^80 {(k^81:c)(s=9)1 } [-203F7(^82^4A5B5)(^84^4A5B6)(^85^4A5B6)(^88^4A5B7) (^89=1)(^8A=1)]-203F7 } [-3551:^80(^82^B3E5)(^84^4A5B8)(^85^B3E6)(^88^B3DB)(^8A=1)(^86=237) (^87^48403)] @$$}307}@ In my case deleting this entry prevents the deletion of history. I hope this information will help the developers to locate the cause of the problem. I don't know if it means anything, but this entry is the first entry after passing file size of 1024000 bytes, aka before entry 306 the file size was below 1024000 bytes, adding entry 306 increases the file size above 1024000 bytes and here comes the previously quoted entry 307.

I have another entry which causes firefox to erase history. Deleting this ensures normal operation. @$${505{@ <(4AD5D=1107680613175550)> {1:^80 {(k^81:c)(s=9)1 } [-2072C(^82^4AB5A)(^84^4AD5C)(^85^4AD5C)(^88^49895) (^89=1)(^8A=1)]-2072C } [-1FBF7:^80(^82^49521)(^84^4AD5D)(^85^49522)(^88^49523)(^8A=1)(^86=10) (^87^49524)] [-1FBF8:^80(^82^49525)(^84^4AD5D)(^85^49526)(^88^49523)(^87^49527) (^86=9)] @$$}505}@ The last entry was number 51e. Is there a developer who could solve this x-file?

(In reply to comment #25) > I did some research and found that in my last case the following entry in > history.dat caused firefox to erase the whole history: This was good work :). Unfortunately I cant confirm it yet, as I stopped using Firefox, but if someone could pursue this path, it would be great. Furthermore a build with the modifications mentioned by Parish would be greatly appreciated : ).

Again, great work. I can confirm that on build "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050201 Firefox/1.0+" once my history got above 1024, the next time I closed and reopened Mozilla, my history was completely gone. It's looking to be more of a filesize issue than a specific entry issue. Are there any users out there who haven't had this happen, with history files over ~1MB in size?

If it is size related then there are at least two issues here, my history file is cleared once every couple days or so. I haven't seen a history file even near 1024 since pre 0.9 days.

I wouldn't say it's a size problem (or mainly a size problem), because my history is now over 1.5MB and it hasn't been erased in the the last 3.5 days. It seems that deleting those critical entries made the history more stable. I would encourage you Tim and Timo to try to find the entry which causes your problem. Always save the history after exiting Firefox and when it gets deleted start deleting entries from it. I use binary search, it's only a few minutes to find the critical entry. Developers, do you have any idea??

(In reply to comment #30) > Always save the history after exiting Firefox and when it gets deleted start > deleting entries from it. I use binary search, it's only a few minutes to find > the critical entry. The problem is (at least in my case), the history gets sometimes also deleted during an active browser session. > > Developers, do you have any idea?? I still think it might be a synchronisation issue.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050212 Firefox/1.0+ This started to happen pretty frequently in latest nightly builds, at least on my install.

Ok, here is another entry which results in complete history loss: @$${B4C{@ <(4D1A4=http://elle/)(4D1A5=1108367493859375)(4D1A6=elle)(4D1A9 =http://ella/)(4D1AA=1108367504437500)(4D1AB=ella)(4D1AC=keyword:ella) (4D1AD=G$00o$00o$00g$00l$00e$00 $00k$00e$00r$00e$00s$00$E9$00s$00:$00 $00e$00\ l$00l$00a$00)(4D1AE =http://www.google.com/search?hl=hu&q=ella&btnG=Keres%C3%A9s&lr=lang_hu) (4D1AF=1108367510437500)> {1:^80 {(k^81:c)(s=9)1 } [-21BC4(^82^4D1A4)(^84^4D1A5)(^85^4D1A5)(^88=elle) (^89=1)(^8A=1)] [-21BC5(^82^4D1A7)(^84^4D1A8)(^85^4D1A8)(^88^4D1A3)(^89=1)(^8A=1)]- 21BC5 -21BC3 [-21BC6(^82^4D1A9)(^84^4D1AA)(^85^4D1AA)(^88=ella)(^89=1)(^8A=1)] [-21BC7(^82^4D1AC)(^84^4D1AA)(^85^4D1AA)(^88=)(^87^4D1AD)] [-21BC8(^82^4D1AE)(^84^4D1AF)(^85^4D1AF)(^88^499A5)(^87^4D1AD)]} @$$}B4C}@ The history.dat is about 2 300 000 bytes, and deleting this item restores normal operation. It seems that it has nothing to do with file size. Furthermore, I have plenty of entries after this errorneous one. I hope a developer will soon look at this bug...

I have actually been seeing this "bug" since 1.0 Final but have not reported it because I was unable to duplicate it. It occurs on both SP1 and SP2 for me with clean install on SP2. I can confirm that it occurs with a new or old profile, with or without extensions. My history and location bar are both cleared at unknown intervals. I have posted on Mozillazine and several people there have reported the same problems

I and other users according to Mozillazine have experienced this with 1.0.1 update also. Sometimes it can occur during a browsing session in addition so that rules out the improper closing/crash scenario.

Not that I would have expected something different (the bug is still open and there are no official responses), but I can still confirm the bug with 1.0.1.

Does anyone know how FFx handles the live bookmarks? I have not experienced this problem in the past with versions that did not include the RSS live bookmarks (<0.9). I did not start using the live bookmarks until 1.0 final and that was when I first noticed this. Could updating a live bookmark produce a erroneous entry in the history.dat file when it updates? I am by no means a programmer, just trying to find some correlates.

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0 (In reply to comment #37) > I have not experienced > this problem in the past with versions that did not include the RSS live > bookmarks (<0.9). I did not start using the live bookmarks until 1.0 final and > that was when I first noticed this. Same for me.

I have never used the LiveBookmark feature of Firefox, and have experienced this on all machines I've installed it on. Unlikely that it's RSS related.

(In reply to comment #39) > I have never used the LiveBookmark feature of Firefox, and have experienced this > on all machines I've installed it on. Unlikely that it's RSS related. I'll agree with that, I've experienced this before I used the Live Bookmarks.

It seems there are more people affected by this bug than previously thought due to responses on Mozillazine. It may be because more people are using Firefox and the percentage of users affected is still the same. These are the conclusions we have from the forum discussion: 1) It defintely occurs on Windows. No reports on Linux or OSX. 2) Does not seem to be affected by live bookmarks. 3) Does not seem to be affected by extensions installed. Occurs with or without extensions. 4) Occurs with new profile 5) Occurs with Clean Windows install (No spyware or malware except M$ installed) 6) No correlation with a specific site visited 7) Possible correlation with the size of the history.dat file but unknown. 8) Can occur during a browsing session 9) Seen in 0.9 and later, may also have occured in previous versions but unreported 10) Theme does not matter 11) Plug ins do not matter, occurs with no plugin installation of FFx 12) Appears completely random 13) History days setting/cache settings do not affect when or whether this occurs 14) Bookmarks, cache, saved forms, passwords, and other parts of the profile NOT lost 15) Firewall software does not matter

(In reply to comment #41) > It seems there are more people affected by this bug than previously thought due > to responses on Mozillazine. Could you post #25, #26, #30 and #33 (or a summary) to Mozillazine? Maybe others could find other bogus items and hopefully this would lead to faster fix of the bug. Since my last bogus item report (and deletion of the item) I haven't encountered the bug!

Since the history is completely cleared when I experience this bug, shouldn't there be no bogus entries within the history itself to cause problems? As comment #31 stated, it can occur during an active session (same for me) so digging through the history.dat file would have to be an active process with FFx running and constantly copying history.dat every time it changes instead of just copying the history.dat file after FFx closes. How did you go about finding which history entry was the critical entry? I will post your comments on my thread at Mozillazine and see if anything happens. (In reply to comment #42) > (In reply to comment #41) > > It seems there are more people affected by this bug than previously thought due > > to responses on Mozillazine. > > Could you post #25, #26, #30 and #33 (or a summary) to Mozillazine? Maybe others > could find other bogus items and hopefully this would lead to faster fix of the bug. > > Since my last bogus item report (and deletion of the item) I haven't encountered > the bug!

OK, I spun a debug build and copied the history entry from comment 25 into my history.dat. FF asserted and I broke to the debugger. It's barfing at this point in the record (mStream_At): (^84^4A5B6)(^85^4A5B6)(^88^4A5B7) (^89=1)(^8A=1)]-203F7 } [-3551:^80(^82^B3E5)(^84^4A5B8)(^85^B3E6)(^88^B3DB)(^8A=1)(^86=237) (^87^48403)] in morkBuilder::OnValueMid() at if ( cell ) { morkBookAtom* atom = store->MidToAtom(ev, valMid); if ( atom ) cell->SetAtom(ev, atom, store->StorePool()); else ev->NewError("undefined cell value alias"); } store->MidToAtom(ev, valMid) is returning NULL The top of the stack trace is: nsDebugImpl::Assertion(nsDebugImpl * const 0x01fc3138, const char * 0x014a44a4, const char * 0x014a4762, const char * 0x014a4730, int 56) line 295 nsDebug::Assertion(const char * 0x014a44a4, const char * 0x014a4762, const char * 0x014a4730, int 56) line 109 mork_assertion_signal(const char * 0x014a44a4) line 56 + 31 bytes morkEnv::NewError(const char * 0x014a5614) line 404 + 19 bytes morkBuilder::OnValueMid(morkEnv * 0x03599b78, const morkSpan & {...}, const morkMid & {...}) line 953 morkParser::ReadCell(morkEnv * 0x03599b78) line 611 morkParser::ReadRow(morkEnv * 0x03599b78, int 40) line 678 morkParser::ReadTable(morkEnv * 0x03599b78) line 789 morkParser::ReadContent(morkEnv * 0x03599b78, unsigned char 1) line 1432 morkParser::ReadGroup(morkEnv * 0x03599b78) line 1222 morkParser::ReadAt(morkEnv * 0x03599b78, unsigned char 0) line 1254 morkParser::ReadContent(morkEnv * 0x03599b78, unsigned char 0) line 1439 + 16 bytes morkParser::OnPortState(morkEnv * 0x03599b78) line 1473 + 14 bytes morkParser::ParseLoop(morkEnv * 0x03599b78) line 1531 + 12 bytes morkParser::ParseMore(morkEnv * 0x03599b78, int * 0x0012d380, unsigned char * 0x0359d7ec, unsigned char * 0x0359d7ed) line 1570 morkThumb::DoMore_OpenFileStore(morkEnv * 0x03599b78) line 479 morkThumb::DoMore(morkEnv * 0x03599b78, unsigned int * 0x0012d428, unsigned int * 0x0012d44c, unsigned char * 0x0012d42f, unsigned char * 0x0012d426) line 399 + 12 bytes morkThumb::DoMore(morkThumb * const 0x0359d7dc, nsIMdbEnv * 0x03599ba4, unsigned int * 0x0012d428, unsigned int * 0x0012d44c, unsigned char * 0x0012d42f, unsigned char * 0x0012d426) line 194 nsGlobalHistory::OpenExistingFile(nsIMdbFactory * 0x0359917c, const char * 0x0352bbd0) line 2665 + 38 bytes nsGlobalHistory::OpenDB() line 2606 + 33 bytes As to why it's barfing I don't know. I don't know enough (read anything) about Mork databases so I'll have to go and read up about them before I can do anymore, but maybe this will help a developer or allow them to point me in the right direction.

Has happened to me randomly on all FF milestone releases from 0.9.x to 1.0.1, on both Windows 98 and Windows 2000. It may have occured before 0.9, I don't remember. Firefox clears the history on startup, if that helps. Also, I have a dual boot with Windows 98 and 2000, and I share one profile between both. Both OS's have Avast! Antivirus and Spybot S&D.

Not to offend anyone new, but from here on out, can we refrain from spamming the bug with more comments along the lines of "it happens to me". That is the purpose of the voting mechanism in bugzilla. PLEASE read a bug fully before posting a new comment to it, and only then if there is information to add, and you aren't repeating something that is already there. If you wish only to state that it also happens to you, PLEASE VOTE for the bug instead. Thank you.

The cause seems to be missing timestamps. Someone on the n.m.firebird NG sent me a complete historyfile that showed the problem. I tracked the rogue entry down to: @$${C33{@ {1:^80 {(k^81:c)(s=9)1 } -1025 -[-102B(^82^2478)(^84^250F)(^85^2479)(^88^247A) (^8A=1)(^86=3)(^87^247B)]} @$$}C33}@ There is no value for "variable" 250F - in (^84^250F), 84 being LastVisitDate - but add one: @$${C33{@ <(250F=1110596631125000)> {1:^80 {(k^81:c)(s=9)1 } -1025 -[-102B(^82^2478)(^84^250F)(^85^2479)(^88^247A) (^8A=1)(^86=3)(^87^247B)]} @$$}C33}@ and the file doesn't get deleted. The whole entry still looks wrong - there's no URL for a start - but at least that doesn't cause the history file to be lost. I can repeat that with the entry in comment 25 as well. As to why this data is missing, I don't know. FWIW, in the file I have, the previous history entry is yahoo.com and the subsequent one is ar.atwola.com - which is a ad feed for Yahoo. Could it possibly be that FF starts a new history entry (for an ad/pop-up page) and then the browser is redirected (as happens with ad sites) before the page loads but FF isn't removing the partial entry? Probably not, I'm just thinking out loud.

I've backed up my history cos of this bug, and it keeps happening (eventually) with the history file I have. I've recently installed the SessionSaver extension from extensionsmirror.nl and every time I close Firefox, it seems to lose the history. Can anyone else replicate this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050328 Firefox/1.0.2 and sessionsaver extension?? Do you want me to create an attachment with my history?

James, please read the previous comments. This is not caused by extensions.

I realise that, but I did also say that it happened eventually without the extension, too. I just thought it was interesting that the extension sped up the process. Unless that's something totally different.

I've experienced this bug several times. Sometimes it seemed to occur randomly, other times it seemed like it was related to deleting addresses from the address bar. I have finally found a way to consistently make it happen: Go to any site listed in the address bar. Now open the address bar again and select the address of the current site from the list, without clicking it. Press shift+delete. Now close firefox. When firefox is opened again, the old history file will be replaced with a blank one. I'm sure this exact series of events isn't what's causing the bug for everyone, but I hope that it will help you to track down the problem. The history does not always seem to be cleared if another site is visited after deleting the address, or if the address bar is not opened while the deletion takes place. (That is, if the address is just highlighted & backspaced) I have also noticed that the problem always occurs when I use my real history file, but if I start a new one with just a few addresses, the problem doesn't occur. My real history file is 3.2mb, but even if I delete most of the entries and get it down to 80kb, the bug still occurs.

Whether or not this is a seperate bug from the one discussed here, I'm not sure, but I just wanted to confirm the "testcase" in comment #51. If you follow his directions, it does indeed wipeout the history file the next time you open Firefox. Currently I'm using 1.0.3 (final) on XP. It seems to do this even with as few as three entries in the history file, and I can reproduce it EVERY time. Note though, it DOES NOT seem to work if you have multiple tabs open when you try it, you have to be using only one tab when you test this. Hopefully with a constantly reproduceable test-case we can make some progress with this (fingers crossed).

(In reply to comment #52) (I am using FF 1.0.4) I may well have deleted the URL for a site displayed during the session after which the history disappeared, although it was most certainly not the last site visited and the history file remained intact until the end of the session. This has occurred only one time to me (so far). > Whether or not this is a seperate bug from the one discussed here, I'm not sure, > but I just wanted to confirm the "testcase" in comment #51. If you follow his > directions, it does indeed wipeout the history file the next time you open > Firefox. Currently I'm using 1.0.3 (final) on XP. It seems to do this even with > as few as three entries in the history file, and I can reproduce it EVERY time. > Note though, it DOES NOT seem to work if you have multiple tabs open when you > try it, you have to be using only one tab when you test this. Hopefully with a > constantly reproduceable test-case we can make some progress with this (fingers > crossed).

It seems like Josiah has hit the nail on the head in comment 51. For the first time ever, I experienced this bug. What I had done just before closing FF was to remove entries (using Shift-Delete) from the Search bar dropdown rather than the URL bar. I used the test case in comment 51 and can reproduce this consistently although, as comment 51 notes, it doesn't seem to happen with only a few entries - I seem to need at least 10 or so. I opened history.dat in an editor after closing FF, but before re-opening it, and found corrupt entries as per my investigation in comment 47, so it appears that when you delete history entries from dropdowns using Shift-Delete that FF doesn't completely remove the entry in the file resulting in the corruption that causes it to be zapped and a new one created.

I experience this bug about 4 or 5 times a day when I browse alot. I have not noticed any connection with using Shift+Delete to remove history entries. I can simply open and close FF a few times and find the history has disappeared.

Same problem with me. I´m using Windows 2000 and mozilla fire 1.0.4... history.dat comes 0kb and everything is gone... My bookmarks, my download directory... everything but not my history where i have been.... Ok fix this, it accors with 2 computers.

Same here...deleted an entry using shift+delete -> history gone.

why not a blocker? pretty serious issue.

I just experienced this using Firefox 1.5 beta 1. Very annoying...

I can confirm this. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Win XP SP2

This has been happening to me for quite a long time (at least since 0.8, I'm sure of it). My history just ups and deletes itself. Sometimes I've had it go as long as a week or two without it happening, but it always does. I've created a new profile, and that doesn't help either. Currently running 1.0.7.

I just lost my firefox history running 1.5 rc1. I noticed this immediately after clearing the cache and restarting firefox. However, the reason I was clearing the cache was that the disk partition holding my profile had filled up. So maybe the loss of history was due to a full disk. I've not checked if it does, but it would be a good idea if firefox didn't delete the old history.dat file until it knows it has enough space to create the new one. I've never seen this problem before, but then again I've never run out of disk space or emptied the cache before. Perhaps this should be filed as a separate bug? I don't know.

Either mozilla developers are too stupid to fix this kind of bugs or they have a plot against their users. I'm inclined to think this is a plot against their users because they can't be so stupid to have such simple bugs open for more than a year. Could you use Berkeley DB http://www.sleepycat.com/ or a SQL database like MySQL or PostgreSQL? FOR THE LOVE OF GOD!!! Please use one of these databases and when someone knows how to fix the performance issues and the data loss issues at the same time you can change back to the current **** solution!!!

The history system is currently being changed to use a SQLite back-end, targetted for Firefox 2.0.

(In reply to comment #64) > The history system is currently being changed to use a SQLite back-end, > targetted for Firefox 2.0. Great to know! Thanks for sharing with all of us without asking (sarcasm!). Could you let us also know where this was discussed? What branch or code or patch should I check to have this fix in my code? Why are you targeting a critical bug to a new mayor release? I thought critical (data loss) bugs where targeted to the next minor revision. I mean it can't be worst, as the current **** code is already losing data!!!

David: please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html points 1.1 and 1.3 carefully. I think it's pretty obvious why the major rework of history system (the switch to SQLite) can't be done for a minor point release. I think that if you figure out how to fix this issue with a reasonably small patch, it may be accepted for a minor point release (drivers make this decision). Apparently it was decided that fixing this bug in current code is not top-priority, and posting inflamatory comments like comment 63 is not likely to change that decision.

(In reply to comment #67) > David: please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html > points 1.1 and 1.3 carefully. Nickolay, David did neither abuse anyone nor posted a pointless comment. Hence your > Apparently it was decided > that fixing this bug in current code is not top-priority, and posting > inflamatory comments like comment 63 is not likely to change that decision. Well, thats the point. Such a decision would be plainly wrong. This bug is not a negligible minor one, but a severe major bug which regularly causes data corruption respectively data loss in the browser's most basic structure. Just as a sidenote, if this bug would exist within Firefox' dearest enemy, the usual suspects within the open source scene would once again cry out loud how bad it is. For how long is this bug now already known? Soon two years?!

Oops ;) (In reply to comment #68) > > Nickolay, David did neither abuse anyone nor posted a pointless comment. Hence > your .... reply is rather incorrect.

(In reply to comment #68) > > Apparently it was decided > > that fixing this bug in current code is not top-priority, and posting > > inflamatory comments like comment 63 is not likely to change that decision. > > Well, thats the point. Such a decision would be plainly wrong. This bug is not > a negligible minor one, but a severe major bug which regularly causes data > corruption respectively data loss in the browser's most basic structure. Note the "in current code" part, and see comment 64.

(In reply to comment #70) > > Note the "in current code" part, and see comment 64. Sorry, but what do you want to say?

I'm trying to say that fixing this rare occurence in current code isn't a priority because Firefox 2.0 will have a new history back end.

(In reply to comment #72) > I'm trying to say that fixing this rare occurence in current code isn't a > priority because Firefox 2.0 will have a new history back end. > Well, looking at this history of this bug report I wouldnt exactly say its rare. Even worse, its reproducible and yet not a single developer cares about it. Again, this bug isnt a minor one but one which affects one of the most basic data structures of the application and causes there data corruption and data loss. Ignoring such an error for almost two years and hoping that it might be fixed by a complete rewrite isnt exactly a professional attitude.

"Reoccurring" (ie - this bug) is not the same as "reproducible". Reproducible implies that this bug can be triggered 100 percent of the time, for everyone. To my knowledge there has never been a definitive test case for this problem. Without a test case, rare bugs like this become almost impossible to troubleshoot. It may be a HUGE problem when it does happen for you, but you have to realize that it IS rare. If it happened to all 50+ million (assuming) people that have used Firefox, do you really think more of a commotion wouldn't have already been made about this?

(In reply to comment #74) > To my knowledge there has never been a definitive test case for this problem. Then you might want to read comment #51.

(In reply to comment #74) > To my knowledge there has never been a definitive test case for this problem. Even more, this statement is absolutely contrary to what you said in comment #52.

Alexander, calm down. That was 1.0.3. If you aren't paying attention, we're currently at 1.5., as such, I haven't seen this bug personally in about 5-6 months. "Reproducible still" should have been my statement instead, for that I apologize. Either way, this will be cleared up with the new history/bookmark backend, so in that regard, this is being worked on.

(In reply to comment #77) > Alexander, calm down. That was 1.0.3. If you aren't paying attention, we're > currently at 1.5., as such, I haven't seen this bug personally in about 5-6 > months. "Reproducible still" should have been my statement instead, for that I > apologize. Tim, since you seem to be lost. I'm going to write down the procedure to lost you history, please try it for yourself and let us now. Get Firefox on Linux. I'm personally using: http://ftp.es.debian.org/debian/pool/main/f/firefox/firefox_1.5.dfsg-3_i386.deb Now run Firefox. Fill your home partition with data until is full. (cat /dev/zero >> ~/delete.me) Browse a little bit. Close the browser. Run the browser again. Dude, where's my history? > Either way, this will be cleared up with the new history/bookmark backend, so > in that regard, this is being worked on. That's not enough for a critical bug.

(In reply to comment #77) > Alexander, calm down. That was 1.0.3. If you aren't paying attention, we're > currently at 1.5., as such, I haven't seen this bug personally in about 5-6 > months. "Reproducible still" should have been my statement instead, for that I > apologize. I have to admit, I dont know how on earth you got the impression I might not be calm .... anyway, I am just presenting the facts and criticise the (non-)response of the developer team in this case. And yes, I still experience this bug with 1.5. > > Either way, this will be cleared up with the new history/bookmark backend, so > in that regard, this is being worked on. Well, thats exactly what is not being done. It is NOT being worked on, it is simply ignored and probably replaced in a future version with a - for other reasons - completely rewritten version. This is not the kind of reaction I expect for a serious bug concerning data integrity.

I seem to have this same bug on Fedora Core 4, FF 1.5.0.1. (So the field 'OS' for this bug isn't covering all atm) Every +/-7days my urlbar history is simply gone. It might happen when the extension 'Session Manager' asks about restoring a session. But i'm not sure about that. Will try and investigate a bit more the next time.

(In reply to comment #80) > I seem to have this same bug on Fedora Core 4, FF 1.5.0.1. (So the field 'OS' > for this bug isn't covering all atm) > Every +/-7days my urlbar history is simply gone. > Yes, this bug is basically ignored and I think it wont be fixed at all, but will only disappear with version 2.0, when the current history system is replaced with a SQL database.

(In reply to comment #78) > (In reply to comment #77) > > Alexander, calm down. That was 1.0.3. If you aren't paying attention, we're > > currently at 1.5., as such, I haven't seen this bug personally in about 5-6 > > months. "Reproducible still" should have been my statement instead, for that I > > apologize. > > Tim, since you seem to be lost. I'm going to write down the procedure to lost > you history, please try it for yourself and let us now. > > Get Firefox on Linux. I'm personally using: > http://ftp.es.debian.org/debian/pool/main/f/firefox/firefox_1.5.dfsg-3_i386.deb > Now run Firefox. > Fill your home partition with data until is full. (cat /dev/zero >> > ~/delete.me) > Browse a little bit. > Close the browser. > Run the browser again. > Dude, where's my history? > > > Either way, this will be cleared up with the new history/bookmark backend, so > > in that regard, this is being worked on. > > That's not enough for a critical bug. > Exactly the same behavior here. If the disk is full when Firefox exits the history is gone. I realize that it's impossible to save the new history with a full disk but why can't it simply fall back to the previously saved copy? This is a grave bug that causes data loss and is 100% reproducible. What's the plan to fix it?

Since this bug will be fixed due to the bookmarks/history "Places" overhaul in Firefox 2.0, I doubt any energy is going to be expended on this bug at this point.

I wonder if this can be worked around by having the wrapper script save a copy of the history file at startup, so that if FF discards it then the user at least has the option to restore it manually.

> I wonder if this can be worked around by having the wrapper script save a copy > of the history file at startup, so that if FF discards it then the user at > least has the option to restore it manually. > Yes. In fact there is a nice extension that does this: http://www.pikey.me.uk/mozilla/?addon=bb Despite its name it can backup any data you have in profile.

(In reply to comment #83) > Since this bug will be fixed due to the bookmarks/history "Places" overhaul in > Firefox 2.0, I doubt any energy is going to be expended on this bug at this > point. > You mentioned this before and I still think it is rather unacceptable to leave such a critical bug in released versions. It renders Firefox 1.x rather almost unusable - I know I am exaggerating a bit, but I guess you get the point. (In reply to comment #84) > I wonder if this can be worked around by having the wrapper script save a copy > of the history file at startup, so that if FF discards it then the user at > least has the option to restore it manually. > This wont help much because the bug also appears while Firefox is running.

(In reply to comment #86) > (In reply to comment #84) > > I wonder if this can be worked around by having the wrapper script save a copy > > of the history file at startup, so that if FF discards it then the user at > > least has the option to restore it manually. > > > > This wont help much because the bug also appears while Firefox is running. > This bug is actually at least 2 distinct bugs: the shift-delete with a single tab issue and the disk-full issue. And it would still help because losing the changes made to the history during the current session is not nearly as bad as losing the entire history.

(In reply to comment #87) > > And it would still help because losing the changes made to the history during > the current session is not nearly as bad as losing the entire history. > You lose the entire history in any case.

(In reply to comment #88) > You lose the entire history in any case. > No, you don't. If my good history file was saved before launching FF, and the bug hits and my history disappears, I can close FF and manually restore the old history file.

(In reply to comment #89) > > No, you don't. If my good history file was saved before launching FF, and the > bug hits and my history disappears, I can close FF and manually restore the old > history file. > Well, thats obvious that you will not lose it if you saved it manually before.

Umm... please reread comment #84

As Places will finally not be part of Firefox 2 (see http://weblogs.mozillazine.org/ben/archives/010109.html for details), will this bug be treated ?

I _think_ this is caused by not doing a CompressCommit after cutting the row. That's what normally happens when a page is removed through the history API. I also copied over the CutAllColumns call, for consistency (this should really go through the history API so that observers are notified! but that will be a larger patch). With this patch, I'm unable to reproduce the problem.

Comment on attachment 223569 [details] [diff] [review] patch Looks like, uh, Mork code all right.

Comment on attachment 223569 [details] [diff] [review] patch what brettw said...

checked in

Comment on attachment 223569 [details] [diff] [review] patch I'd really like this to be considered for FF 1.5.0.4, as well.

Comment on attachment 223569 [details] [diff] [review] patch Too late for 1.8.0.4, moving request

Comment on attachment 223569 [details] [diff] [review] patch approved for 1.8.0 branch, a=dveditz for drivers Please land on the 1.8 branch as well.

> I'd really like this to be considered for FF 1.5.0.4, as well. If you don't land it by Monday morning builds you're not going to make 1.5.0.5, either.

checked in (was already on the 1.8 branch, I just forgot to mark it)

Josiah: Any chance you have tried reproducing this with the latest 1.8.0 nightlies? If you have a chance, can you verify this fix with the latest Firefox 1.5.0.5 rc3 build (you can get it at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/1.5.0.5-candidates/rc3/). If anyone has seen this problem, it will be nice to get some more testing to make sure the dataloss is gone.

(In reply to comment #102) > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/1.5.0.5-candidates/rc3/). > > If anyone has seen this problem, it will be nice to get some more testing to > make sure the dataloss is gone. > Is there a .deb that works with Ubuntu Dapper? I don't have the cycles or time to compile it but I could test a binary. I've hit this bug twice this week already.

Lee, there is good news! The file named firefox-1.5.0.5.en-US.linux-i686.tar.gz in the directory Jay linked to IS a binary. Just untar it, cd to "firefox" and run ./firefox.

(In reply to comment #102) > Josiah: Any chance you have tried reproducing this with the latest 1.8.0 > nightlies? If you have a chance, can you verify this fix with the latest > Firefox 1.5.0.5 rc3 build (you can get it at > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/1.5.0.5-candidates/rc3/). > > If anyone has seen this problem, it will be nice to get some more testing to > make sure the dataloss is gone. > I used to experience this bug on a weekly (or more frequent) basis both at home and at work. After upgrading to 1.5.0.5rc3 at home and a nightly at work, I have not experienced this in about two weeks. If nothing else, it's at least significantly less frequent. Thanks, -[Unknown]

I can confirm that I haven't experienced any history loss in the three weeks since I've switched to builds containing this fix (on three separate systems). Previously I was losing my entire history on all of them at LEAST once a week. Thank you SO MUCH for getting this in for 1.5.0.5... I can finally recommend Firefox to people without crossing my fingers that they won't some day ask me about where all their "drop-down bar stuff" went. :)

v.fixed on 1.8.0 branch based on the last few comments, glad to hear people aren't losing there data anymore! :-)

Using the steps in comment #78 and using firefox 2.0b1 http://ftp.es.debian.org/debian/pool/main/f/firefox/firefox_1.99+2.0b1+dfsg-1_i386.deb I'm still losing the history. Could you guys test this bug using latest firefox 2.0 release and reconfirm that this bug exists? Should I reopen this bug or open a new bug report?

@David, I think this is only fixed in 1.8.0.5, not 2.0b1.

(In reply to comment #109) > @David, I think this is only fixed in 1.8.0.5, not 2.0b1. > That's incorrect, the fixed1.8.1 keyword means it landed on the branch for Fx2 (Gecko 1.8.1). But the fix wasn't for a "disk full" case, just the random history loss. One bug per report as they say.

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

Agreed. The disk filling up completely is a different case from this. The bug mentioned here IS fixed (almost 4 weeks and counting on three boxes with no occurrence).

Well, my comment #82 was about the disk filling up. What's the bug ID# for that one? When will that be fixed?

Lee, why not just tryout the extension mentioned in comment #85? It seems to be a solution for you in the meantime. I don't believe there is a current bug open for the specific case of the disk being full and losing history as a result.

Because I'd rather get the bug fixed than work around it. It's completely unacceptable to lose data when the disk fills up.

Um... okay. But if there's a solution out there that will prevent you from losing data... why would you not use it exactly?

I don't really have the bandwidth to go installing various extensions to work around bugs. It's easier for me to just make sure the disk never fills up.

I've just filed bug #346003 for the "history lost when exiting with disk full" issue.

Can this bug can be closed now since we've moved the databases from Mork to SQL?

I would be much more convinced that these bugs are gone when that piece of **** of Mork is purged from Mozilla codebase. Do you have any plans to purge Mork?