From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90) BuildID: 2000101014 after I selected outlook express and pressed 'next' nothing happens...the 'cancel' button does still work. Reproducible: Always Steps to Reproduce: 1... 2. 3. Actual Results: nothing Expected Results: ... It worked in NS6 previous beta...

changing QA contact - not migration

I don't use the default M$ 'mail dir' path.

adding tony to the cc list.

Mark, was this on a trunk build? this sounds like a regression of #52086. I don't see this bug on the rtm branch, but I did see it on the tip over the weekend.

I just checked today's trunk and rtm branch build. looks ok on both. marking dub. *** This bug has been marked as a duplicate of 52086 ***

I'm using nigthly (or daily..?) build 2000102320 now and it works. Only the result window stayed empty and I only could push the cancel button. In the address book I could see that the adresses where imported.

So, the actual bug is that the results window is empty and the Cancel button remains active rather than a Finish button. A patch is attached to fix this. The new import wizard UI requires status text for the results window in order to continue - outlook express address book import was not returning any status text, in either success or failure cases.

Reassigning the bug to me.

I assume with the .properties file change that it's too late for this but it would be nice to go ahead and get the fix into the trunk.

Perhaps we could get this one fixed?

*** This bug has been marked as a duplicate of 83103 ***

I am not convinced that this bug is a duplicate of #83103. This is about 'importing' Outlook Express into Mozilla. But #83103 makes available the Outlook Express Address Book dynamically to Mozilla.

Reopening due to clarification.

Setting QA Contact to Fenella.

If you select "Outlook Express" and click on Next You will notice that Outlook Express Address Book has been imported. change summary to reflect the actual bug.

The last dialog with the cancel button show "Importing mailbox from outlook express" even though I chose to import address book

Marking nsbranch, because the Cancel button should appear as a Finish button. Currently this is confusing, although the address book cards are actually imported.

There aren't any comments on this bug since the 16th of Sept. Can QA regess against the Netscape commercial builds and determine if this is still a valid bug? If so, and we can get fixes/reviews in the next day or two, please mark as nsbranch+ which will get this on the PDT radar. Else, mark is as nsbranch-. Also, can someone comment in the bug how serious you think this is? PDT is only accepting "stop ship" bugs such as data loss and loss of major functionality.

I think based on current criteria, this bug needs to be nsbranch-.

I agree.

This is a bug I just saw today. I was performance testing the addressbook code, and had to import a 1,000 entry addressbook from Outlook Express 6 (Windows 98), and ran across this same bug exactly. I'm nominating this.

reassigning to srilatha.

reassigning to shliang.

1) + nsCOMPtr<nsIStringBundle> bundle(dont_AddRef( nsOEStringBundle::GetStringBundleProxy())); can you explain why we aren't addreffing here? 2) + nsString success; + nsString error; Do these have to be heap based strings? Could we use stack based nsAutoStrings? 3) + nsString name; + PRUnichar * pName; + if (NS_SUCCEEDED(source->GetPreferredName( &pName))) { + name = pName; + nsCRT::free(pName); + } I think you can do this, instead + nsString name; + PRUnichar * pName; + if (NS_SUCCEEDED(source->GetPreferredName( &pName))) { + name.Adopt(pName); + } 4) + + nsCOMPtr<nsIStringBundle> pBundle = nsOEStringBundle::GetStringBundleProxy(); + PRUnichar *pFmt = nsOEStringBundle::GetStringByID(OEIMPORT_ADDRESS_SUCCESS, pBundle); + PRUnichar *pText = nsTextFormatter::smprintf(pFmt, name.get()); + pStream->Append(pText); + nsTextFormatter::smprintf_free(pText); + nsOEStringBundle::FreeString(pFmt); + ImportOEMailImpl::AddLinebreak(pStream); Why not use FormatStringFromID()? I think that's what you want here.

OK, about #4, you'll have to extend nsOEStringBundle and define a FormatStringFromID(). the import code is such a mess. so much duplicated code, see C:\builds\bridge\mozilla\mailnews\import\eudora\src\nsEudoraStringBundle.cpp C:\builds\bridge\mozilla\mailnews\import\oexpress\nsOEStringBundle.cpp C:\builds\bridge\mozilla\mailnews\import\outlook\src\nsOutlookStringBundle.cpp C:\builds\bridge\mozilla\mailnews\import\src\nsImportStringBundle.cpp C:\builds\bridge\mozilla\mailnews\import\text\src\nsTextStringBundle.cpp but that's another bug.

duplicated bundle code, moved to http://bugzilla.mozilla.org/show_bug.cgi?id=131040

added FormatStringByID to nsOEStringBundle

fixed with cavin's check-in to bug 82791

it seems that cavin's fix fixes this by avoiding an error in import. but what if there is another one? I think we want these changes, although we can wait until later.

Marking nsbeta1, another polish bug (see comment# 18).

Mail Triage: nsbeta1-

so attachment 75306 [details] [diff] [review] has not been tested / checked-in?

> so attachment 75306 [details] [diff] [review] has not been tested / checked-in? no, it hasn't (looking at lxr.) but see also #82791, where calvin made some changes back in 2002 that would now collide with this patch.