Bookmarks and upgrade/downgrade fun
In Places, we use a SQLite database as the canonical location for bookmarks data. The first time you run Firefox 3 (or Minefield until then), it populates the database by importing Firefox 2’s bookmarks.html. To make it easy to continue to use 3rd party tools that use bookmarks.html, Firefox 3 continues to write to bookmarks.html the contents of the Places database on a regular basis.
That presents a problem in the following scenario: What happens when a user tries out Firefox 3 (e.g., by installing the upcoming beta), goes back to Firefox 2, then upgrades again to Firefox 3 when it is released? That does not seem like a very unlikely scenario, and it will result in any changes since the downgrade to be thrown away upon starting Firefox 3 again.
I’ve been worried about this problem for some time, and have so far advocated that we simply don’t touch bookmarks.html after initial import (see bug 381216). But after discussing it more today with Mike Connor and Seth Spitzer, I no longer think that is going to work. Why? Because allowing bookmarks.html and places.sqlite to diverge after initial import technically solves dataloss, but practically, it doesn’t. One can argue that the user can go back to Firefox 2, manually export, and import into Firefox 3… except for one little detail: most people won’t install in parallel, they will update. That is, if you try the beta, and then you either install Firefox 3 on top, or you wait until major update happens, then you won’t have Firefox 2 installed, and the fact that your bookmarks.html contains your bookmark changes since you ran the beta won’t help you one bit (unless you know how to look for it, but most people won’t).
So we’re damned if we touch bookmarks.html, and we’re damned if we don’t. What else is there? We can attempt to determine if there were any real changes in bookmarks.html (Mike suggested coming up with a simple list of URLs in bookmarks.html and checking if they all are in places.sqlite), but that still leaves the problem of what to do when there are changes.
The first thing that comes to mind is, well, to merge. But I’m not sure that given the short time-frame we can make that a reality. Perhaps we could do some sort of dumbed-down merge, where we simply grab the bookmarks.html tree and stick it into a folder. Or we do that, but only insert bookmarks that don’t already exist in the places db. Overall, though, I don’t like these options.
Alternatively, we could drop the places bookmarks tables and re-import. Since in Firefox 2 you’d be editing the places-exported bookmarks.html, and you can only run one browser at a time on any given profile, by dropping the db and re-importing you wouldn’t lose any Firefox 3 bookmarks changes. You would, however, lose any Firefox 3-specific data, such as item annotations that aren’t exported to bookmarks.html. Still, maybe this option isn’t so bad, specially if we only do something so drastic when there are “real” changes (not just a new favicon or a last-visited timestamp change).
We’ve considered and rejected many other variants of the above, like having an extension to enable bookmarks.html, or only overwriting bookmarks.html if it hasn’t been changed, or changing the behavior for the beta somehow. We’ve even considered shipping an update to Firefox 2 now, to change it in some way that helps us. Every option that I’ve considered so far, frankly, sucks.
So, what do you think we should do?