Note that current 115 ESR is 115.10.0, so you are two major versions behind.

• https://www.mozilla.org/en-US/firefox/organizations/notes/

You would need an older copy of places.sqlite that contains older history.

When was this profile created? What is the content of times.json?

You can use the button on the "Help -> More Troubleshooting Information" (about:support) to go to the current Firefox profile folder or use the about:profiles page (Root directory).

• Help -> More Troubleshooting Information -> Profile Folder/Directory:
  Windows: Open Folder; Linux: Open Directory; Mac: Show in Finder
• https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data

I've been behind with Firefox versions for a long time; every time I update, something else works worse. Was that just a general observation, or could that have something to do with what's happening here?

about:profiles says:

Profile: default This is the profile in use and it cannot be deleted.

The root directory has files going all the way back to 2012, so I assume that's how old the profile is.

The local directory leads to a profiles folder that is EMPTY.

Library/Application Support/Firefox/Profiles/jplidtng.default/times.json

just said this:

created 1335517288000

I eventually found places.sqlite; when I clicked on it, it said I didn't have an application to open it…?

Unix Epoch 1335517288000 means 2012-04-27T09:01:28.000Z, so that confirms that the profile got created in 2012. You can use this online SQLite viewer tool to inspect places.sqlite, but that probably won't tell you much.

• https://inloop.github.io/sqlite-viewer/

Did you previously had this older history? How much history do you have in case you run out of the maximum history visits?

Current Firefox versions keep a maximum number of visited page and do not have a time limit for the history. Firefox determines automatically how many pages can be kept without affecting performance. In current releases you can find this value if the click "Verify Integrity" on the "Help -> More Troubleshooting Information" (about:support) page.

• History can store a maximum of xxx unique pages

You can check the size of these tables in "Verify Integrity" and "View Statistics":

moz_places has xxx records
moz_historyvisits has xxx records

places.sqlite turns out to contain:

Drop file here to load content or click on this box to open file dialog. id name 3 downloads/destinationFileURI 5 URIProperties/characterSet 10 downloads/metaData

My history previously went back to 2020 for sure, and possibly to 2019 or earlier.

Moz_historyvisits has 218,891 rows. Here is the final page:

id from_visit place_id visit_date visit_type session source triggeringPlaceId 827913 827912 450397 1713571718454124 1 0 0 827914 0 451617 1713571902507447 1 0 0 827915 827914 451791 1713571902814978 6 0 0 827916 827915 451792 1713571903507467 6 0 0 827917 827916 451793 1713571904377763 6 0 0 827918 827917 451794 1713571905096157 1 0 0 827919 0 40746 1713572733800405 1 0 2 827920 827919 451795 1713572748543590 1 0 0 827921 827920 451796 1713572755932165 1 0 0 827922 827921 451797 1713572904009330 1 0 0 827923 827921 451797 1713573038363202 1 0 2

And I think I found the other stuff you asked about:

Entity Count Size (KiB) Size (%) Efficiency (%) Sequentiality (%) sqlite_schema - 32 0 24.2 45 moz_places 118792 36576 51.4 99.1 45 moz_historyvisits 218890 5856 8.2 99.1 45 moz_inputhistory 147 32 0 11 45 sqlite_autoindex_moz_inputhistory_1 - 32 0 7.4 45

So... anyone?

You could be exceeding the maximum for moz_historyvisits.

In current releases you can find this maximum for moz_historyvisits if you click "Verify Integrity" on the "Help -> More Troubleshooting Information" (about:support) page, look for this entry:

• History can store a maximum of xxx unique pages

Verify integrity gave this:

> Task: checkIntegrity + The places.sqlite database is sane + The favicons.sqlite database is sane > Task: invalidateCaches - The task queue was cleared by an error in another task. > Task: checkCoherence - The task queue was cleared by an error in another task. > Task: expire - The task queue was cleared by an error in another task. > Task: originFrecencyStats - The task queue was cleared by an error in another task. > Task: vacuum - The task queue was cleared by an error in another task. > Task: stats - The task queue was cleared by an error in another task. > Task: _refreshUI - The task queue was cleared by an error in another task.

It doesn't say anything about maximum unique pages. Moz_historyvisits doesn't exist on that page.... But I tried the thing that copies out the raw data, and I found this:

"entity": "moz_historyvisits",

     "count": 220347

I certainly haven't generated anywhere in the universe of that many history entries in the year and a few months that's all the history I have left, so it doesn't look like this is an issue of too many history entries…?

You are rather close with "count": 220347 since you previous reply showed moz_historyvisits: 218890

"Verify Integrity" shows that there is a problem with the places.sqlite database and Firefox may have to create a new places.sqlite what will cause all history to get lost, for the bookmarks there are backups in the bookmarkbackups folder that Firefox can use to rebuild the places database.

If errors are reported with "Verify Integrity", close and restart Firefox or reboot and retry. If "Verify Integrity" cannot repair places.sqlite, rename/remove all places.sqlite and favicons.sqlite files in the Firefox profile folder with Firefox closed. Firefox will rebuild places.sqlite and restore the bookmarks from the most recent JSON backup in the bookmarkbackups folder.

• keep a backup copy of places.sqlite in case a new places.sqlite database has to be created
• you lose the history when a new places.sqlite is created

You may have to restore an earlier bookmarks backup in the bookmarkbackups folder via the Bookmarks Manager (Library).

• Bookmarks -> Manage Bookmarks -> Import & Backup -> Restore
• https://support.mozilla.org/en-US/kb/restore-bookmarks-from-backup-or-move-them

See also:

• https://support.mozilla.org/en-US/kb/fix-bookmarks-and-history-will-not-be-functional
• https://support.mozilla.org/en-US/kb/cant-add-change-or-save-bookmarks

You can use the button on the "Help -> More Troubleshooting Information" (about:support) to go to the current Firefox profile folder or use the about:profiles page (Root directory).

• Help -> More Troubleshooting Information -> Profile Folder/Directory:
  Windows: Open Folder; Linux: Open Directory; Mac: Show in Finder
• https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data

Let's assume for the moment that this disaster has occurred because I was at the maximum allowable number of history entries. Let's further assume that the system is designed to delete YEARS of old entries at a time, rather than a month or so at a time. How on earth could I have possibly generated YEARS worth of history entries in the less than 2 weeks since much of my history vanished?

I couldn't have! Which makes it seem to me that those missing entries, or the vast majority of them, MUST still exist somewhere, where they are still being counted towards my total.

I haven't lost ALL my history, and it sounds like what you're describing is what could eliminate ALL history… Does that also apply to my situation? I'm a little nervous about deleting a bunch of system level files and hoping it doesn't mess something up... And in particular, I definitely do NOT want to lose the history I have left! It won't actually help me to lose the history I have in order to get older history back which I would not use as often… And in the other stuff you're saying, you keep talking about bookmarks, I'm not sure if you mean history or if you've kind of lost track of which they were talking about.

Firefox has been quit and restarted several times since this issue became known; no change.

Anyways, to clarify, I'm looking to recover my lost history WITHOUT losing the 15 months or so of history that I have left, which is of course the historical period that I access the most.

So, I've dug up all of this in-depth information… Does anyone have any ideas about how I can retrieve the missing history, and WITHOUT losing my more recent history?

I put in a lot of time digging up and providing a bunch of information… Is there any way to actually USE all this information to find the missing history?

Lisa, did you try rerunning the verify integrity check after restarting Firefox / your computer? Did it still report errors?

Verify integrity gave me:

> Task: checkIntegrity + The places.sqlite database is sane + The favicons.sqlite database is sane > Task: invalidateCaches + The caches have been invalidated > Task: checkCoherence + The database is coherent > Task: expire - The task queue was cleared by an error in another task. > Task: originFrecencyStats - The task queue was cleared by an error in another task. > Task: vacuum - The task queue was cleared by an error in another task. > Task: stats - The task queue was cleared by an error in another task. > Task: _refreshUI - The task queue was cleared by an error in another task.

I'm still hoping that someone can help me with this. I'm continuing to lose my oldest history, although not on a day by day basis.... Now my history goes back a year, 3 months, and 17 days. So, back to February 11; previously, it was January 19.

As of what both results of "Verify Integrity" indicate then your only option is to start with a fresh places.sqlite although you can try to repair the database.

• https://superuser.com/questions/111998/how-do-i-repair-a-corrupted-firefox-places-sqlite-database

Make sure to keep backup copies of places.sqlite and favicons.sqlite, so you can try another way if one doesn't work.

This is a level of technical stuff that's far above my head… Does repairing the database bring back the missing history? Wouldn't starting with a "a fresh places.sqlite" delete all the history I have left?

Lisa, repairing the database might restore old data, I don't think you can know until you've tried it.

Deleting the files altogether will indeed lose all history, plus possibly any new bookmarks made in the last day or two.

I would recommend you do something though, rather than persist with a corrupted database. You never know when a corrupted file might cause problems or lose further chunks of data.

You say that so casually, like you're suggesting I change a lightbulb, lol… I have no idea whatsoever how to repair a database anywhere, or to do anything in the universe of that level of technical wizardry! Quite aside from the fact that everything in my database is showing as "sane" or "coherent," so there's no evidence that there's anything TO fix in the database! Where would I go, what would I do, to find this secret hidden database corruption that doesn't show up in the report, and then how would I fix it?

Suggesting that I just "do something," take random action just for the sake of acting, is NOT helpful! Suggesting that I deliberately destroy my entire remaining history with no explanation of how that would bring me any gain whatsoever, much less the gain I'm looking for, is also NOT helpful!

What WOULD be helpful is telling me where to find the missing history and how to put it back, or even just to access it in any way.

Secondarily, any suggestions on how to stop my history from losing a day every day, by which I mean a proven procedure for fixing this issue, not, "delete all your remaining history and see if that magically fixes things," would also be helpful.

And an update; my history seems to be holding steady at 1 year, 3 months, and 17 days. That seems a little too neat and tidy and regular and consistent to be caused by corruption, doesn't it? Everyone agrees that the amount of history you can have is based on the number of pages, which in my case are only HALF of the amount available, so how is it holding to a steady # of days? The answer to that question might lead to a solution!

Lisa, some aspects of the database may have passed the verify integrity test but others did not, as errors were found. Plus there is the evidence of the fact that you have lost / can't access previous data, and seemingly continue to keep losing more.

The gain with deleting the current file is that Firefox would create a fresh, uncorrupted file and start again. You could then expect a normal history system, i.e. one that doesn't consistently lose data.

If rather than deleting the original file you moved it to a different folder and kept it, you could always move it back if you later change your mind.

That said, if you want to 100% rule out corruption in the file, and see if something else within your profile might be deleting data from the file, you could try copying places.sqlite into a brand new profile and see if it keeps losing data.

Or you could instead try increasing the max number of history visits and see if that helps.

Unfortunately I cannot give detailed instructions on this, I am just trying to give some possible alternative options to consider aside from following the repair instructions in the link given above, or deleting and starting over.