if import outlook express fails, problems with the cancel/next/finished buttons.

NEW
Unassigned

Status

SeaMonkey
MailNews: Address Book & Contacts
18 years ago
3 years ago

People

(Reporter: Mark van Beek, Unassigned)

Tracking

({polish})

Trunk
x86
Windows ME
polish

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

18 years ago
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...

Comment 1

18 years ago
changing QA contact - not migration
Component: Profile Migration → Address Book
QA Contact: gbush → esther
(Reporter)

Comment 2

18 years ago
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 6

18 years ago
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.

Comment 7

18 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Comment 8

18 years ago
Reassigning the bug to me.
Assignee: sspitzer → tonyr

Comment 9

18 years ago
Created attachment 18057 [details] [diff] [review]
Fix for importing outlook express addr. book

Comment 10

18 years ago
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [rtm need info]

Updated

18 years ago
Whiteboard: [rtm need info]

Updated

18 years ago
QA Contact: esther → nbaca

Comment 11

18 years ago
Perhaps we could get this one fixed?

Comment 12

17 years ago

*** This bug has been marked as a duplicate of 83103 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 13

17 years ago
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.

Comment 14

17 years ago
Reopening due to clarification.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 15

17 years ago
Setting QA Contact to Fenella.
QA Contact: nbaca → fenella

Comment 16

17 years ago
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.
Summary: import outlook express addresbook → import outlook express addrbk,Cancel button s/b finish button

Comment 17

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

Updated

17 years ago
QA Contact: fenella → nbaca

Comment 18

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

Comment 19

17 years ago
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.

Comment 20

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

Comment 21

17 years ago
I agree.
Keywords: nsbranch → nsbranch-

Updated

17 years ago
Blocks: 107067

Updated

17 years ago
Keywords: nsbranch-
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.
Keywords: nsbeta1

Comment 23

17 years ago
reassigning to srilatha.
Assignee: tonyr → srilatha
Status: REOPENED → NEW

Updated

17 years ago
Keywords: nsbeta1 → nsbeta1+
Priority: P3 → P1
Target Milestone: --- → mozilla1.0

Updated

17 years ago
Priority: P1 → P2

Comment 24

17 years ago
reassigning to shliang.
Assignee: srilatha → shliang

Comment 25

17 years ago
Created attachment 73150 [details] [diff] [review]
patch
Attachment #18057 - Attachment is obsolete: true

Comment 26

17 years ago
Created attachment 73151 [details]
screenshot
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.

Comment 30

17 years ago
Created attachment 75306 [details] [diff] [review]
patch with seth's changes

added FormatStringByID to nsOEStringBundle
Attachment #73150 - Attachment is obsolete: true

Comment 31

17 years ago
fixed with cavin's check-in to bug 82791
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Keywords: nsbeta1+ → nsbeta1-
Resolution: WORKSFORME → ---
Summary: import outlook express addrbk,Cancel button s/b finish button → if import outlook express fails, problems with the cancel/next/finished buttons.
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 33

16 years ago
Marking nsbeta1, another polish bug (see comment# 18).
Keywords: nsbeta1- → nsbeta1, polish
Mail Triage: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Product: Browser → Seamonkey

Comment 35

12 years ago
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.
Assignee: shliang → mail
Status: REOPENED → NEW
QA Contact: nbaca → addressbook
Priority: P2 → --
Target Milestone: mozilla1.0.1 → ---
You need to log in before you can comment on or make changes to this bug.