457109 - importBookmarksHTML imports from JSON backup if it exists, clones "Recently Bookmarked" and "Recent Tags"

Status: RESOLVED DUPLICATE of bug 462366

(Firefox :: Bookmarks & History, defect)

Description

[Toby Ovod-Everett]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; MS-RTC LM 8)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2) Gecko/2008091620 Firefox/3.0.2

The browser.places.importBookmarksHTML setting appears to have some serious bugs, at least in Firefox 3.0.2.  If there is a JSON backup in the <Firefox_profile>\bookmarkbackups folder, then it behaves completely differently from the documentation in http://kb.mozillazine.org/Browser.places.importBookmarksHTML.  If it finds a JSON backup, it ignores the bookmarks.html file and instead imports whatever is in that bookmarkbackups folder, and then it leaves the setting set to "true"!  This means that changes made to the bookmarks don't persist, since the JSON backup is done once each day at the beginning of the day, and so any changes you make that day keep getting lost whenever you open Firefox!  If you want to do bi-directional synchronization between multiple profiles using importBookmarksHTML in conjunction with autoExportHTML, you have to toast the bookmarkbackups folder and set browser.bookmarks.max_backups to 0 so that Firefox no longer does JSON backups!  At which point it starts behaving as described.

Except that every time you do an import from bookmarks.html file, it clones the "Recently Bookmarked" and "Recent Tags" dynamic folder thingies!  BTW, to aid testing, stick the importBookmarksHTML setting in the user.js file where Firefox can't reset it (but do the JSON testing without a user.js file so you can see that it doesn't get set to false like the documentation shows).

It does look like the Tag information, for instance, persists in the places.sqlite file through an import, although if you delete a shortcut from the bookmarks.html file it does get deleted from the menu during import, but that Tag information isn't persisted through the bookmarks.html file, so that information wouldn't make it through a rebuild and wouldn't make it from machine to machine.


Reproducible: Always



Expected Results:  
importBookmarksHTML should import from bookmarks.html and reset to false independently of whether there is a JSON file in the bookmarkbackups folder.

importBookmarksHTML should not repeatedly clone the "Recently Bookmarked" and "Recent Tags" folders.

I am using browser.bookmarks.file to redirect the bookmarks.html file for the purposes of autoExportHTML and importBookmarksHTML and that appears to be working correctly in both instances (provided there are no JSON backups lying around during the importBookmarksHTML step).

This isn't an urgent issue for us - we've decided to store the Mozilla profiles out in our per-user network home directories.  I stumbled across all of this while testing various alternatives for dealing with the whole https://bugzilla.mozilla.org/show_bug.cgi?id=385077 . . . . ummm . . . issue.  :-)

Comment 1

[Toby Ovod-Everett]

The cloning problem also appears to affect the "Most Visited" folder in the Bookmarks toolbar.

Comment 2

[Marco Bonardo [:mak]]

if i had seen this before i would not have open a new bug, hwv since new bug has more info and a wip patch i'm duping to that.

Comment 3

[Toby Ovod-Everett]

My initial testing of 3.5 shows that all of the issues have been resolved cleanly.

In case anyone else is searching for behavior to mimic the old 2.x bookmarks.html behavior, try adding the following to your user.js (not prefs.js) file:

user_pref("browser.bookmarks.file", "path_to_bookmarks.html_with_doubled_backslashes");
user_pref("browser.bookmarks.autoExportHTML", true);
user_pref("browser.places.importBookmarksHTML", true);

By adding these settings to the user.js file, we ensure that they cannot be modified by Firefox.  Specifically, this prevents Firefox from updating the "browser.places.importBookmarksHTML" value to false.  Actually, it does change it to false in the prefs.js file, but whenever Firefox opens it overrides that value with the one in the user.js file, thus ensuring that the setting persists indefinitely.

Observed behavior:
 * When Firefox exits, bookmarks.html is updated (based on autoExportHTML)
 * When Firefox opens, bookmarks.html is read and used to update existing bookmarks
 * Tags and other Firefox 3 fringe benefits appear to persist through the update process
 * The update process will both create and delete entries in the Bookmarks tree
 * If Firefox crashes (or is crashed by killing the process), the bookmarks.html file does not get updated with any changes during that session, and those updates will be lost when Firefox is next opened.  This is a potential for loss of bookmarks.
 * If the bookmarks.html file is inaccessible when Firefox is started, it leaves the existing bookmarks alone.
 * Standard "last Firefox to close wins" behavior seen in previous versions.

This provides a simple synchronization/backup mechanism for Firefox 3.5 bookmarks that largely mimics the 2.x behavior, with the exception that if Firefox crashes after changes are made to the bookmarks but before Firefox exits cleanly, those changes are lost.