383070 - Profile migrator should detect/offer Thunderbird profiles when no SeaMonkey 1.x profiles exist

Status: RESOLVED FIXED

(SeaMonkey :: Startup & Profiles, defect)

Description

[Mark Banner (:standard8)]

If you have no SeaMonkey/Mozilla/Netscape profiles but you do have Thunderbird profiles, and you start suiterunner with no existing profiles or via the migrator, then you don't get the option to migrate your Thunderbird profiles.

This is because the profile migrator is assuming that all profiles are browser based.

I've already got a partial fix for this, will clean it up and attach it when I get time.

Comment 1

[Worcester12345]

I think I mentioned in another bug that it would be nice to ask at the startup of the "profile migration and conversion utility" that it would be great if it gave all the options in both the to: and from: areas. Isn't this common (core) code which can be shared by all applications?

Comment 2

[Mark Banner (:standard8)]

(In reply to comment #1)
> I think I mentioned in another bug that it would be nice to ask at the startup
> of the "profile migration and conversion utility" that it would be great if it
> gave all the options in both the to: and from: areas. Isn't this common (core)
> code which can be shared by all applications?

Yes and I'm fairly sure I replied that that is not possible. If you wish to raise a bug on it it should be raised under toolkit as that is where we can't get profile data from.

Comment 3

[Mark Banner (:standard8)]

Attachment: Possible Fix

I've not had chance to test this yet, but I think it should work. Basically on Windows we try and get the default browser as the one to select - unfortunately we've not got migrators for all the options - so, if we don't find a matching one, fallback to looking for existing SeaMonkey or Thunderbird profiles like Linux & mac do straight off.

Comment 4

[Worcester12345]

(In reply to comment #2)
> (In reply to comment #1)
> > I think I mentioned in another bug that it would be nice to ask at the startup
> > of the "profile migration and conversion utility" that it would be great if it
> > gave all the options in both the to: and from: areas. Isn't this common (core)
> > code which can be shared by all applications?
> 
> Yes and I'm fairly sure I replied that that is not possible. If you wish to
> raise a bug on it it should be raised under toolkit as that is where we can't
> get profile data from.
> 

Looks like Bug 383052 – FF and TB need an additional migrator option for new SMv2.0 (a.k.a. suiterunner)

takes up this idea in comment 1.

Comment 5

[Mark Banner (:standard8)]

Attachment: Fix v2

Fixes this issue and a possibly some other problems with detecting profiles. On windows we don't have a migrator/profile for the default browser (or we don't understand the internal name) we'll now fallback to the mac/unix way of trying to detect profiles for each of the migrators, until we run out or find one where a source profile exists.

Comment 6

[[e-mail]]

Comment on attachment 268840 [details] [diff] [review]
Fix v2

>+struct sInternalNameToMigartorName {
Typo: s/Migartor/Migrator/

>+      if (internalName.LowerCaseEqualsLiteral(nameMap[i].internalName)) {
I know the external API allows this, but you're only supposed to use string literals, hence the name of the function? There are other cases, I haven't bothered to point them all out. r=me with this fixed.

>+    migratorID.AssignLiteral(NS_SUITEPROFILEMIGRATOR_CONTRACTID_PREFIX);
(I wonder whether we can save anything by setting this once and then using SetLength to reset the suffix each time.)

Comment 7

[Mark Banner (:standard8)]

Patch checked in with comments addressed.

(In reply to comment #6)
> >+    migratorID.AssignLiteral(NS_SUITEPROFILEMIGRATOR_CONTRACTID_PREFIX);
> (I wonder whether we can save anything by setting this once and then using
> SetLength to reset the suffix each time.)

I decided to leave this as I don't think it'll give us that much and I think we won't be using it that much.