Likely partly related to the places.sqlite.corrupt file I now have for the history. https://bugzilla.mozilla.org/show_bug.cgi?id=1415133 https://bugzilla.mozilla.org/show_bug.cgi?id=1416506 I will now attempt to simply rename the file and remove the old places.sqlite file as per this guy's successful attempts. https://support.mozilla.org/en-US/questions/1187781

Keep us posted.

Cormy1 said

Upgraded from 56.0.2 to 60.4ESR and now any customization I do to the UI through the customize button is reset on browser close.

https://support.mozilla.org/en-US/kb/how-to-fix-preferences-wont-save

Note: Some software, like Advanced SystemCare with Surfing Protection, can protect files in the Firefox profile folder against changes. If you have such software then check the settings or uninstall this software.

As a footnote to Fred's post, you can look for these changes to further diagnose the problem:

(1) After rearranging toolbar buttons, you should see this preference customized in about:config:

browser.uiCustomization.state

Its contents are hard to read because the controls list is packed together without spaces, but it will at least be bolded and marked as modified.

(2) Within a minute the change should be reflected in the prefs.js file in your profile folder (Profiles - Where Firefox stores your bookmarks, passwords and other user data)

To view a .js file, I suggest creating a copy and renaming it with a .txt extension (otherwise, Windows may try to execute the script when you open it). So that involves:

• Set Windows to show the .js extension on files: https://www.bleepingcomputer.com/tutorials/how-to-show-file-extensions-in-windows/
• Single-click prefs.js to select the file, press Ctrl+c to copy, press Ctrl+v to paste -- Windows should creates prefs - Copy.js
• Right-click prefs - Copy.js and change the extension from .js to .txt

Now you can safely open the file and view its contents. When a preference has been customized in about:config, it should be added to this file.

(3) After exiting Firefox, the prefs.js file should not be deleted or reverted to its earlier state; the change should persist through Firefox shutdowns and restarts indefinitely.

So I've discovered the reason why I ran into this problem in the first place is because I have 2 versions of Firefox installed. When I open the older version, it attempts to use the places.sqlite file within the profile folder (both versions clearly try to access the same folder/profile) however since that places.sqlite file has been updated, it is unintelligible to the older Firefox version, so it is renamed to a corrupt file and a new places.sqlite is generated. I will attempt to workaround this issue by creating a new profile and instructing the older Firefox to use the other profile, as I have no way of making the modified places.sqlite readable by the old Firefox version. Then I will run a Sync to try and get the history copied over to that profile.

Oh... you didn't mention anything older than Firefox 56. I don't think pre-56 versions can handle the structure in 56+.

Several databases were changed as to how they work, making them incompatible.

If you want to keep both versions, you will need to create separate profiles for each.

If you want to use just one version, you need to remove the other version.

A full clean reinstall would be best.

jscher2000 said

Oh... you didn't mention anything older than Firefox 56. I don't think pre-56 versions can handle the structure in 56+.

Is 52.9ESR built on an older structure than 56? I don't quite understand how the ESR development cycle functions, I just saw that the 52 ESR branch had support longer than 56 had so I figured it would be an upgrade.

ESR is a "long term maintenance" release track which, well, let me give you a link: https://www.mozilla.org/firefox/organizations/

jscher2000 said

ESR is a "long term maintenance" release track which, well, let me give you a link: https://www.mozilla.org/firefox/organizations/

That page really REALLY doesn't give enough details to properly answer my question. Does going from 56.0.2 to 52.9ESR corrupt the places.sqlite file? Is 56.0.2 history unreadable to 52.9ESR? I've also noted that during some shenanigans I ended up losing my old places.sqlite file which was about 46MB of history. Having regained that history through Firefox sync, my current places.sqlite file hasn't grown in size at all for some reason, and is still the base size. Why is that? Does 60.0.4ESR not store history in the places.sqlite file any longer?

Cormy1 said

jscher2000 said

ESR is a "long term maintenance" release track which, well, let me give you a link: https://www.mozilla.org/firefox/organizations/

That page really REALLY doesn't give enough details to properly answer my question.

I didn't include a quote, but your question that I was responding to was:

Cormy1 said

Is 52.9ESR built on an older structure than 56? I don't quite understand how the ESR development cycle functions, I just saw that the 52 ESR branch had support longer than 56 had so I figured it would be an upgrade.

Are those questions now answered?

Regarding your new questions:

Does going from 56.0.2 to 52.9ESR corrupt the places.sqlite file?

Firefox 52 cannot use the places.sqlite file from Firefox 56. As far as it is concerned, the file is corrupted. But the file may still work in Firefox 56+. There are past threads on this but I have not tried it myself.

Is 56.0.2 history unreadable to 52.9ESR?

History is stored in places.sqlite, so Yes.

I've also noted that during some shenanigans I ended up losing my old places.sqlite file which was about 46MB of history. Having regained that history through Firefox sync, my current places.sqlite file hasn't grown in size at all for some reason, and is still the base size. Why is that? Does 60.0.4ESR not store history in the places.sqlite file any longer?

All relevant versions of Firefox store history in places.sqlite. The size of .sqlite files on disk is enlarged in huge chunks and does not accurately indicate the volume of contents. In order to compare the volume of contents, you would need to use a utility that can read the contents and indicate what's in there, or extract their contents into a form that can be compared (e.g., text dump).