when a user goes from fx 2 -> fx 3 beta -> fx 2 -> fx 3, should we import fx 2 bookmarks.html if it is newer than places.sqlite? in bug #381216 comment #30, thunder writes: One note, allowing Fx2 & Fx3 bookmarks to diverge means that if a user tries the beta, then goes back to Fx2 and continues to use that until major update, it may feel to them like they lost some bookmarks (even though they'll still be there in bookmarks.html). If you install in parallel you can open up Fx2, but if you don't you'll have to just know to browse to your profile to find your bookmarks. It'll probably (?) be a small percentage of users, but maybe we could prompt to re-import around major update time (just once)? It could use a heuristic, like your places.sqlite mtime being more than N weeks/months older than your bookmarks.html mtime. Or maybe instead of prompting, we could simply copy bookmarks.html into the backups dir. If we name it something like "Bookmarks (Firefox 2)", it won't get expired and it'll be obvious what to do in the menu, provided they check the menu at all.
(In reply to comment #0) > when a user goes from fx 2 -> fx 3 beta -> fx 2 -> fx 3, should we import fx 2 > bookmarks.html if it is newer than places.sqlite? Thanks for logging this spinoff bug. I don't think we should re-import every time bookmarks.html is newer--that would cause us to have dataloss the other way around (throw out Fx3 changes). We could of course attempt to merge, but I don't think it's worth spending a lot of time on this bug. Rather, my suggestion is ask/re-import/show in the backup menus only once, at some point before major upgrade. I think ideally what we really want is to do it on first-run when the previous version was Fx2, but I don't think we keep track of what the previous version was; only that it was different. I guess we could do something via the installer as well, but that sounds hacktastic.
> I don't think we should re-import every time bookmarks.html is newer- Oops, I didn't mean to imply that, thanks for clarifying. I highly recommend everyone read http://blog.mozilla.com/thunder/2007/08/02/bookmarks-and-upgradedowngrade-fun/ to get a good grasph of this problem.
> I think ideally what we really want is to do it on first-run when the previous > version was Fx2, but I don't think we keep track of what the previous version > was; only that it was different. I guess we could do something via the > installer as well, but that sounds hacktastic. That might be good enough, though. Low bar: when we detect a "move up" situation, if the sqlite file already exists and is older than the bookmarks.html file, we can throw a dialog that says "if you modified any of your bookmarks in a previous version of Firefox, you'll need to reimport them" High bar: when we detect that case, we import/merge, stripping duplicate entries
Wanted, but there's much bigger fish to fry.
We're long past the point of this being needed. ->WONTFIX
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.