185689 - implement profile migration from IE to Mozilla

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: Migration, enhancement)

Description

[Dan M]

In the "wouldn't it be nice..." category, today's entry is an unexalted but
possibly convenient ability to import Internet Explorer profile information to
Mozilla. User preferences, cookies; that sort of thing.

Comment 1

[Dan M]

Attachment: basic profile migrator handles internet preferences on Windows

Comment 2

[Dan M]

Attachment: handles internet prefs and cookies on Windows

Comment 3

[Alec Flett]

CC'ing conrad because maybe someday we can integrate this into the creation of
the first profile, etc.. (I haven't actually looked at the code just yet, but
thought conrad would be interested)

Comment 4

[Darin Fisher]

Comment on attachment 110773 [details] [diff] [review]
handles internet prefs and cookies on Windows

>Index: extensions/cookie/Makefile.in

> SDK_XPIDLSRCS   = \
> 		nsICookie.idl \
> 		nsICookieManager.idl \
>+		nsICookieManager2.idl \

only frozen interfaces should be added to this Makefile variable.  add
to XPIDLSRCS instead.


>Index: extensions/cookie/nsCookieManager.cpp

>+  char *domainCopy = PL_strdup(PromiseFlatCString(aDomain).get()),
...
>+  PR_FREEIF(domainCopy);

nit: allocator mismatch (potentially).	use PL_strfree instead of
PR_FREEIF.


>Index: extensions/cookie/nsCookies.cpp

>+// caller must hand off ownership of the strings to us.

this calling convention is really unfortunate (*shrug*).

>+      PR_FREEIF(aDomain);

because of the calling convention, it becomes so easy to mix allocators,
but this is really a problem that plagues the entire cookies module --
probably best left for another bug.


>---new file extensions/cookie/nsICookieManager2.idl

>  void addCookie(in AUTF8String aDomain, in AUTF8String aPath,
>                 in ACString aName, in ACString aValue,
>                 in boolean aSecure, in PRUint32 aExpires);

hmm... nsICookieManager has a method named |remove|, so wouldn't it make
more sense to call this method |add|?  also, how about using |unsigned long|
instead of |PRUint32| in the parameter list.

Comment 5

[Conrad Carlen (not reading bugmail)]

Index: xpcom/io/nsDirectoryService.cpp
===================================================================
+++ xpcom/io/nsDirectoryService.cpp	6 Jan 2003 16:47:21 -0000
@@ -399,6 +399,7 @@
 nsIAtom*  nsDirectoryService::sCommon_Desktopdirectory = nsnull;
 nsIAtom*  nsDirectoryService::sAppdata = nsnull;
 nsIAtom*  nsDirectoryService::sPrinthood = nsnull;
+nsIAtom*  nsDirectoryService::sCookiesDirectory = nsnull;

(1) I'd call this new variable "sWinCookiesDirectory" to keep it distict as a
Windows-defined directory. We have cookies, they have cookies...


    // read the entire cookie file
    nsCOMPtr<nsIInputStream> fileStream;
    if (NS_FAILED(NS_NewLocalFileInputStream(getter_AddRefs(fileStream),
                                             cookieFile)))
      continue;


(2) Since you're reading this file in it's entirety in one call, what good is an
input stream object doing here? You could do this with less overhead by just
using nsILocalFile::OpenNSPRFileDesc() and a single PR_Read().

(3) nsCRT::strxxx routines are being used all over. I thought that was out of
favor and we should use std ones that are optimized by compilers.

The table-driven conversion is nice. Does this code get used by mozilla, or is
it just a capability that Gecko-based apps can use? Alec's right - I'd be
interested in adding the few lines it'd take to invoke it during new profile
creation.

Comment 6

[Dan M]

185689
Alrighty. Darin:
SDK_XPIDLSRCS, PL_strdup/PR_FREEIF issues are fixed. I've changed the name of
addCookie to add. However I kept add's PRint-type parameter. Brendan recently
made an argument for explicit sizes in IDL integer parameters. Personally I
can't argue strongly either way and I think (unsigned) long is prettier but in
this case, I prefer PRInt32 because it stands for a time_t type variable, which
are (as far as I know) always 32 bit quantities, no mistake. Of course both
time_t and PRInt32 are typedefed as long so it doesn't really matter but . (But
note I was using PRUint32. I've changed it to PRInt32, because time_t is signed.
Would it be better to define it a native time_t?)

Conrad:
It's sWinCookiesDirectory, I use a PRFileDesc instead of an nsIInputStream and
I've replaced the nsCRT functions in nsTridentPreferencesWin.cpp with libc
functions. (I've left the extant nsCRT things in extant cookies files alone).

Haven't posted an updated patch; these changes are simple and straightforward.

Oh and Conrad, the extension is intended for general use and I don't know
whether Mozilla itself wants this but it's not difficult to use.

Comment 7

[Conrad Carlen (not reading bugmail)]

Comment on attachment 110773 [details] [diff] [review]
handles internet prefs and cookies on Windows

I'll take your word for it. r=ccarlen

Comment 8

[bobj]

cc'd ftang to review the font preference migration

Comment 9

[jag (Peter Annema)]

Comment on attachment 110773 [details] [diff] [review]
handles internet prefs and cookies on Windows

Reminder from our discussion: NS_INIT_ISUPPORTS is no longer needed.

You may be able to get rid of some string header file includes, like
nsLiteralString.h.

sr=jag

Comment 10

[Dan M]

Attachment: add minimal UI and include in windows packages

Comment 11

[Dan M]

Note this is all checked in, but not built by default. To build (Windows-only)
add tridentprofile to your extensions (configure make with
"--enable-extensions=default,tridentprofile" or whatever your combination is.)

The back end works fine (though see bug 188853) but there's some bug in the
simple UI I tacked on at the last minute. It seems like a bug in the chrome
registry but I haven't drilled down on it yet. You have to use a Mozilla profile
created after building with tridentprofile, or add tridentprofile to
chrome/chrome.rdf by hand, else you'll get a parsing error when Mozilla tries to
load its chrome.

Comment 12

[Dan M]

*** Bug 13924 has been marked as a duplicate of this bug. ***

Comment 13

[Jesse Ruderman]

See also bug 101212, import passwords from MSIE.

Comment 14

[Daniel Wang]

MSIE still stores cookies without leading dot. So if imported as is they will
get dropped on restart (see bug 145492). Does Dan's patch address this?

Comment 15

[Dan M]

Migrated cookies won't have a leading dot, and they won't be marked as
domain-type cookies, so nsCookieService won't see them as broken legacy cookies
and won't delete them. I've gone to the trouble to file bug 222343, which is
probably what you meant to do, rather than scribble in an old, closed bug.

Comment 16

[Dan M]

Alright that was rude. My apologies.
But it did feel good.
-- danm wanders off to find someone else to insult, because he liked it.

Comment 17

[Dan M]

Daniel: you were right. Migrated cookies were indeed being imported as domain
cookies, without a leading dot, and they would have been deleted at the next
restart. This is covered, and patched, in bug 222343, where we pretty much came
to that same conclusion after an expenditure of 86 paragraphs. Thanks for
pointing that out.

And this bug isn't closed, whaddayaknow. I wish I could close this bug but I've
never figured out why the UI doesn't work in old profiles.

Comment 18

[Jesse Ruderman]

Firefox now has this feature.  I don't know whether Ben used tridentprofile code.

Comment 19

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 20

[Benjamin Smedberg]

This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.