621974 - Profile migration per -migration doesn't migrate history

Status: NEW

(SeaMonkey :: Startup & Profiles, defect)

Description

[Karsten Düsterloh]

Profile migration per -migration will import into the currently used profile (if any, see bug 621957).
This doesn't migrate any history data, though.

Comment 1

[Robert Kaiser]

It should copy the history.dat and that should be converted by places on encountering it - of course, that only happens if there's no places data there yet.

If it works the way I pointed it out, I suggest WONTFIX.

Comment 2

[Karsten Düsterloh]

I assume by "no places data there" you mean "no places.sqlite exist", because even an empty places.sqlite will deny migration.

The problem is that if you already have profiles, you will always have one of those taken on startup, and this profile will usually have been used before and thus not migrate the history data anymore.

I fail to see how not migrating history just because there already is an sqlite file should be intended behaviour - it's clearly a bug. (Just a case of "not yet implemented", imo.)
If I can start migration manually and can choose the profile where to migrate to, the migration should happen.

Comment 3

[Robert Kaiser]

Feel free to figure out an algorithm that doesn't harm startup perf at all (SeaMonkey is bad enough as it is) and figures out if the given history has already been imported or not and possibly even get that into the places code, which is where all the import is done right now. I won't even waste one thought about that.