I seem to recall the structure of places.sqlite changing a few versions back. I also know that the bookmarks backups have been tweaked recently and in the pre releaser versions the names of the backup files are modified.

I have not even got fx3.6 installed and support for that ceased long ago.

There is a project at present to upgrade some stragglers from unsupported versions to the current versions but I hope that does work and does not result in lost bookmarks. I am not sure but the upgrade may take place in stages and I am not certain of details of the project.

No one is going to make changes to increase compatibility between unsupported verisons of Firefox. However any Mozilla upgrade project should IMO work, and preserve bookmarks, or at least not result in any forced upgrades that will cause unexpected loss of bookmarks.

I will tag this as escalate to see if HelpDesk staff can offer reassurances.

Cheers ^^ I look forward to reading the response =)

The only difference is that a GUID got added and that shouldn't affect the restore as these fields would be ignored. Very old Firefox versions that didn't use JSON.stringify might be more of a problem

• https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/JSON/stringify
• https://developer.mozilla.org/en-US/docs/Using_native_JSON

It is more likely that there is a problem with the places.sqlite file or (less likely) with the JSON backup if you can't restore a JSON backup in the Bookmarks Manager.

Did you try to delete the places.sqlite file before restoring the JSON backup?

Can you open these JSON files in the Scratchpad and have them formatted by clicking the Pretty Print button that the current Firefox release has or does that also throw an error?

See also:

• http://kb.mozillazine.org/Unable_to_process_the_backup_file_-_Firefox

Just tried them to test it, deleting the places.sqlite file results in the same error when importing the JSON file. I also tried opening the JSON in scratchpad, pressed the pretty print button, and saved it as a new JSON, and then tried importing it again, same error message still occurred.

The JSON file itself does not have any intended artifacts/corruption within the file, as it imports perfectly in the older client revisions. It only throws up an error on the newer revisions, so I don't believe it to be the JSON file itself. In addition the other JSON files from the older client also throw up the same error message in the newer client, of which I have 5 of.

Also this install of windows is quite fresh, so it's unlikely to be the firefox profile, or any 3rd party bits of software (I work in IT Tech and Viral analysis, so I'm not the sort to install any kind of PC Doctor program or optimizer, or any other bits of adware that'd slow down or mess things up ^^).

This install is Windows 64bit. My 2nd PC is an old install of Windows XP, from years back, and also had 4.6 version of Firefox from around when it was originally released. That's the one that's auto-updated, and is throwing up the exact same issue, which is why I jumped to the conclusion.

It's probably the Stringify issue you mentioned, although from reading the documentation that seems to be to convert javascript into JSON format, but it's already in JSON format isn't it? Or is that the new JSON format of which you refer to, and the old JSON format is in fact javascript? (Tbh it looks like javascript whichever one I look at, but I'm not experienced with coding for Firefox plugins or otherwise).

If this is the issue, is there any kind of code that can be added to correctly handle the old formats? I've noticed a few people complain about losing all their bookmarks on the upgrade, which is obviously worrying. ^^;

There are a number of operations in the places.sqlite file that are obsolete. For example,

setItemGUID(aItemId, aGUID) Obsolete since Gecko 14.0 - Returns a globally unique identifier for the item. This is mainly for use by extensions that sync bookmark data between different profiles. Old snippit id: "title":"","id":1,"dateAdded":1306666129870000, New snippit {"title":"","guid":"5rkFafJ6AnRZ","id":1,"index":0,"dateAdded":1396387525168000

There is another identifier there that changed I think in version 14 "Note: The method importHTMLFromFileToFolder() method was removed in Gecko 14.0 (Firefox 14.0 / Thunderbird 14.0 / SeaMonkey 2.11)."

But more likely the old is in the Netscape format: http://msdn.microsoft.com/en-us/libra.../aa753582%28VS.85%29.aspx

I tried this though: I installed the old version (3.5) and updated to the current version. All of my bookmarks were there. I had to check for updates and could not skip some steps from 3.5 to 3.6 for example. It then went from 3.6 to 12 then with todays update went straight to 30. All of them are there. However as nothing is perfect, backing up is recommended as well.

Back to your question, making it easier for backwards compatibility, my hypothesis is that they changed with the updates and skipped some versions. The backed up profiles or places.sqlite files may miss this change because the format changes in the update?

My suggestion would be to file a bug with this request, providing a few use cases where this would be needed. Currently only the current version of Firefox is supported , which may leave us to the work around that you are using currently.

Reference: Developer documentation of places

Ah right that's probably what happened. Mine jumped from 3.6 straight to version 30 without doing the updates inbetween. If it's not suppose to do that, but incrementally update, and the latest version is building on code that'd be added on some previous revisions that are inbetween, then that could be what happened.

Does this mean there's a possible bug where the check for version fails on really old clients, and instead of getting the next revision it expects, it instead jumps straight to the latest? That'd be odd, because it'd of been reported before if that was the case. Do you think it's something to do with where Firefox is referring to server side for the next update? For instance, if the next update patch was moved from the original location or the server was updated to handle the requests differently, so the only patch the old clients now see is the very latest version that's been released?

Also, this is my first time posting on the firefox website. How would I file it as a bug with the request attached? I'm not a contributor, or can anyone do it? Had a quick look around, but couldn't find it (Or am I suppose to open a new question and file it under bug there? Is there such a setting?)

In some cases this might be handy, but right now the forum does not have that feature. But there is actually a site [bugzilla.mozilla.org] that is used for this . I do not know what kind of resources this would take, but we can leave it to the professional engineers.

Also I admire that you have all of the information needed for a bug and the steps to reproduce them already, you are ahead of the game :-)

If you would like a reference for a good first bug there is an article for contributors and for anyone located below:

• http://mzl.la/1hB6WbV
• https://developer.mozilla.org/en-US/d.../Bug_writing_guidelines

Thank you again!!

Aha, this post has great timing. I'm having this problem too...

I saved bookmarks with family tree information on Firefox version 5 and am now trying to access it again. The problem is, the filetype is just labeled as "file"... not json or anything. I'm able to open the file through Mozilla and can see code similar to what was given above. I tried to understand the lingo above but couldn't follow... would I be able to install FF version 5 and import the "file" into the bookmarks, then update to v30 and everything would be hunkydorey? What's entailed in installing older versions... uninstall the current and download from somewhere like CNET? Thanks for the help!!

If Windows is hiding the file extension then you may have created an HTML backup and not a JSON backup.

Make sure that the bookmarks backup file has the correct (lowercase) file extension:

• .html for a HTML backup
• .json for a JSON backup

You can check the file type via the right-click context menu of that file and open the Properties. If you are not sure about the file type then you can open the file in Firefox via "Firefox > New Tab > Open File" or "File > Open File". A JSON backup will show as one long text line without line breaks and a HTML backup shows as a web page with clickable links.

A JSON backup starts with: {"title":"","id":1,"dateAdded": An HTML backup starts with: <!DOCTYPE NETSCAPE-Bookmark-file-1>

You need to import an HTML backup and restore a JSON backup.

• Bookmarks > Show All Bookmarks > Import & Backup > Import Bookmarks from HTML
• Bookmarks > Show All Bookmarks > Import & Backup > Restore > Choose File

• Tap the Alt key or press F10 to show the Menu bar.

You can find Show All Bookmarks at the bottom of the list that opes if you click the folder icon next to the star on the Navigation Toolbar.

Thanks for the reply cor-el! Windows only lists it as "File". It starts as a JSON ({"title":, etc) when I open it in Firefox, and I tried the Import & Backup > Restore > Choose File within v30 and the file doesn't show up in the options. Is it corrupt, or do I need to install v5?

Oh this is silly. I played around and added ".json" at the end of the filename. Once I did, I was able to select the file and restore it afterall. Badabingbadaboom! Thanks again.

This happens if you create a backup and forget to add the file extension manually when Firefox didn't add it automatically or you may have removed it when modifying the suggested name.

Awesome, contrasia it looks like I was on the wrong track, please see if this also happened to you. I also did some research and there used to be a bookmarks.html stand alone file in v 3.5 and somewhere in version 12 the bookmarks and history were added in a places.sqlite file. The old bookmarks.html was still there however in newer versions I no longer see this in profile folders.

Firefox 3.5 already has the places.sqlite file and JSON backups in the bookmarkbackups folder. There is usually some migration code that would correct issues when the file format changes, but that won't work with such a large leap from 3.5 to 30.0 (a few version ago also support for old password files signons#.txt has been removed).

I think you were on the right track originally, as Cor-el just pointed out the migration code that corrects issues wouldn't be able to correct for such a large leap. I do have an HTML file, but the HTML file hasn't been updated in such a long time most of the bookmarks are missing, whilst the JSON files I was referring to earlier are in the Bookmarks backup folder and definitely have the extension tagged on the end.

Thanks again for all your help, everyones response in this thread has been really helpful. ^.^

Edit: I just realised I am unable to submit this as a bug however, since I'm not sure how to reproduce it reliably. Since You said you installed 3.4 and managed to update the client through the next revisions reliably without an issue, all the way up to the latest. Mine skipped that, and it's possible a lot of others is doing the same, but if I were to submit that and the developers arn't able to reproduce the jump in revisions, nothing will be done. Hmm..... What to do. Wonder what could be causing it.

You could try to install a Firefox 10 or 17 (ESR) version to see if that allows to import the bookmarks JSON file.

All Firefox releases:

• http://download.cdn.mozilla.net/pub/mozilla.org/firefox/releases/

Be sure to do any testing in a separate profile,

See:

• http://kb.mozillazine.org/Creating_a_new_Firefox_profile_on_Windows
• http://kb.mozillazine.org/Shortcut_to_a_specific_profile
• https://developer.mozilla.org/Mozilla/Multiple_Firefox_Profiles

I'm not sure if the are (were) differences between a JSON backup that Firefox creates automatically in the bookmarkbackups folder or one created manually via the Backup entry in the Library menu Import And Backup.