![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
I accidentally deleted my Firefox browsing history today. I have a backup from a few months ago, so only a few months are lost.
I only intended to delete the cache, cookies, and active logins. It didn't seem to be working (it wasn't logging me out of Dreamwidth) so I tried several times. On maybe the 3rd attempt, Firefox locked up at 50% CPU for a long time, so I terminated Firefox. Only then did I realize my mistake, and that maybe it was using a lot of CPU while trying to delete a decade's worth of history.
Then I checked my profile folder. My places.sqlite file was 71 MB in size, exactly the same size as my last backup. I wondered if maybe my history wasn't really deleted, even though it was no longer showing up in the History view.
So I installed the SQLite Manager add-on and opened the sqlite file.
Surprisingly, the moz_places table still seems to have all my history entries. The only thing which shows that they are deleted is that visit_count is zero, and last_visit_date is blank.
So the site history is still there, just not the dates of when I visited what. Yet, each entry has an ID, and the IDs are in increasing order based on the dates that I had visited the sites.
I have to assume that the entries are still there only because I terminated Firefox while it was in the middle of doing its deletes. According to this bug: Clearing firefox's browser history doesn't change places.sqlite file size, the deleted data should be getting zero-filled even if the file size remains the same. But that comment is 8 years old. The last comment seems to indicate the data may not be actually getting deleted or zero-filled, only hidden.
In comparing the current places.sqlite with the backup, the IDs of the old entries don't match up... the current one seems to be missing entries compared to the old one, even though the total number of entries is only different by 46. So... I guess old entries have been getting deleted automatically by Firefox anyway in the last months, due to the maximum allowed history size.
Hmm.
Let me try the delete again, without terminating it this time. I'll take my shower in the meanwhile. Then I'll check if the entries really get deleted.
Update: Allrighty, over an hour later and the Firefox window still hasn't refreshed, and Firefox is still using 50% CPU. (I'm posting this from a different browser). It can't take that long to clear out 71 MB of data. Or rather 61 MB, as I had earlier decreased the size by running the places maintenance add-on. So it must be looping, or have a serious performance issue. Oh well. I don't have the time to research it more. I'll just revert to my old backed up history.
... After closing Firefox, the places.sqlite file didn't change in size, but the places.sqlite-wal file was over 465 MB! Now after restarting Firefox, the latter file is back down to 37 MB. SQLite Manager is showing that the moz_places table now has about 1000 fewer entries in it (out of 104k) than before. Serious performance issue.
I only intended to delete the cache, cookies, and active logins. It didn't seem to be working (it wasn't logging me out of Dreamwidth) so I tried several times. On maybe the 3rd attempt, Firefox locked up at 50% CPU for a long time, so I terminated Firefox. Only then did I realize my mistake, and that maybe it was using a lot of CPU while trying to delete a decade's worth of history.
Then I checked my profile folder. My places.sqlite file was 71 MB in size, exactly the same size as my last backup. I wondered if maybe my history wasn't really deleted, even though it was no longer showing up in the History view.
So I installed the SQLite Manager add-on and opened the sqlite file.
Surprisingly, the moz_places table still seems to have all my history entries. The only thing which shows that they are deleted is that visit_count is zero, and last_visit_date is blank.
So the site history is still there, just not the dates of when I visited what. Yet, each entry has an ID, and the IDs are in increasing order based on the dates that I had visited the sites.
I have to assume that the entries are still there only because I terminated Firefox while it was in the middle of doing its deletes. According to this bug: Clearing firefox's browser history doesn't change places.sqlite file size, the deleted data should be getting zero-filled even if the file size remains the same. But that comment is 8 years old. The last comment seems to indicate the data may not be actually getting deleted or zero-filled, only hidden.
In comparing the current places.sqlite with the backup, the IDs of the old entries don't match up... the current one seems to be missing entries compared to the old one, even though the total number of entries is only different by 46. So... I guess old entries have been getting deleted automatically by Firefox anyway in the last months, due to the maximum allowed history size.
Hmm.
Let me try the delete again, without terminating it this time. I'll take my shower in the meanwhile. Then I'll check if the entries really get deleted.
Update: Allrighty, over an hour later and the Firefox window still hasn't refreshed, and Firefox is still using 50% CPU. (I'm posting this from a different browser). It can't take that long to clear out 71 MB of data. Or rather 61 MB, as I had earlier decreased the size by running the places maintenance add-on. So it must be looping, or have a serious performance issue. Oh well. I don't have the time to research it more. I'll just revert to my old backed up history.
... After closing Firefox, the places.sqlite file didn't change in size, but the places.sqlite-wal file was over 465 MB! Now after restarting Firefox, the latter file is back down to 37 MB. SQLite Manager is showing that the moz_places table now has about 1000 fewer entries in it (out of 104k) than before. Serious performance issue.
no subject
Date: 2015-10-20 02:38 am (UTC)From:And what version of Windows or else any Linux-type thing are you using with Firefox on it? Again, just curious.
(You shouldn't need the places add-on anymore, either - that goes back many versions.)
(Also, could be a bug with DW mistakenly maintaining log-in state after clearing Firefox cache/history; been through that with DW not too long ago myself.)
no subject
Date: 2015-10-20 03:11 am (UTC)From:I used the places maintenance add-on as I suspected the history file had gotten corrupted, and I read it could repair problems.
I figured out how to consistently recreate the other issue with the Back button. The problem actually happens when I click a link then click the home page icon, then click another link, and then click Back. It does *not* happen in FF safe mode. So one of my add-ons must be causing it. I'll check which one later; it's not that big a deal.