Closed Bug 52086 Opened 24 years ago Closed 24 years ago

address book import wizard non-functional

Categories

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P1)

x86
All

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: dmosedale, Assigned: bugs)

References

Details

(Keywords: regression, Whiteboard: [nsbeta3-][PDTP1][rtm++])

Attachments

(2 files)

In nightly builds from Friday, as well as builds from last night's tip, the
address book important wizard gets to the point of displaying a dialog asking
for the format to be imported, with the single choice of "Text".  Selecting
"Text" causes both the "Last" and "Next" buttons to grey out, and nothing more
happens.  Select Cancel will cause the dialog to go away.
Nominating for nsbeta3, as is this a major loss of functionality.
Keywords: nsbeta3
I'm seeing this also on a linux cvs build from today.  There were no errors on
the console when this occured.  Note that clicking on Text didn't cause anything
to happen.  Then I clicked on Next once and both buttons greyed out instead of
continuing to the import.
Keywords: regression
reassigning to chuang.
Assignee: putterman → chuang
tonyr owns the address book import.  Cc Ben since he touched the import skin 
code last week.
Assignee: chuang → tonyr
This appears to be a XP filepicker problem. Probably something I merged 
incorrectly. Taking. 
Assignee: tonyr → ben
OS: Linux → All
Priority: P3 → P1
Whiteboard: [nsbeta3+]
PDT agrees with P1 priority.
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP1]
would not hold beta 3 for this
Workaround: I went back to M15 and imported an LDIF address book exported from
Communicator 4.72. Then I went back to M17 and could read the address book. It
worked fine, though the group lists did not come through. I'm not sure this is
an acceptable workaround for most users, but for those like me who desperately
want to use Mozilla, it's a good way to go.
PDT folks, so should we skip fixing this in beta 3 and wait for rtm?

Ben, have you found the problem on this one yet?
*** Bug 54029 has been marked as a duplicate of this bug. ***
QA Contact: esther → suresh
OK, since I'm getting no response from the PDT, I'm just gonna assume that we
don't need this for the beta and move it over to RTM-land.
Keywords: rtm
Whiteboard: [nsbeta3+][PDTP1] → [nsbeta3-][PDTP1][rtm+]
*** Bug 54495 has been marked as a duplicate of this bug. ***
Vera: release note
Keywords: relnote3
PDT marking [rtm need info] because we'd like to have a fix for this, after 
patch and code reviews are lined up.
Whiteboard: [nsbeta3-][PDTP1][rtm+] → [nsbeta3-][PDTP1][rtm need info]
*** Bug 54961 has been marked as a duplicate of this bug. ***
Nav triage team: No workaround; remains P1.
*** Bug 55125 has been marked as a duplicate of this bug. ***
is this linux only?  do the file pickers work fine on mac and win32 in this case?

ben, let me know if you want help in tracking this down.
adding dp and me to the cc list.
this patch fixes the problem. I cleaned up a couple of other things too, like
redundant use of top., etc, which I figured may have been causing problems.

One issue remains: itemised results are no longer being shown (what folders were
imported etc) because the ShowImportResults function appears to be called too
early in ContinueImport(). Not sure what that is, and this seems unrelated to my
changes to this dialog around 9/14. However, that is of somewhat lesser
importance than getting this wizard to actually work again.

Status: NEW → ASSIGNED
Keywords: patch
Ben, get this puppy reviewed and approved.
Whiteboard: [nsbeta3-][PDTP1][rtm need info] → [nsbeta3-][PDTP1][rtm need info]Fix in hand, being reviewed
I have a fix in hand for the problem of the results not showing up.   It should
get checked in for bug #54091.  Hopefully that will resolve all of the problems.
 FYI, to fix the results, I had to make a change to attachStrings in
importDialog.js - add an html 'br' element after each line of the results.
r=alecf
These patches fix the problem for me on a trunk build.
r=sspitzer

it works on the branch.

(you do need both js and the xul parts.)

marking rtm+ since r=sspitzer, sr=alecf
Whiteboard: [nsbeta3-][PDTP1][rtm need info]Fix in hand, being reviewed → [nsbeta3-][PDTP1][rtm+]
PDT, this has been reviewed thoroughly by three people now.  If we don't take
this patch, we have a non-functioning address import wizard.  Which would be
bad.  Please "++".
rtm++ since we'd like this to work, and Seth claims that all the lower level
stuff works fine once we fix the XUL.
Whiteboard: [nsbeta3-][PDTP1][rtm+] → [nsbeta3-][PDTP1][rtm++]
fix checked in to branch and trunk. Thanks, alec, seth and scott!
Marking fixed per ben's landing comment.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verified in today's BRANCH builds on all platform!
Keywords: vtrunk
Verified Fixed on trunk builds.  Selecting text import does not gray out the
buttons.
linux 101808 RedHat 6.2
win32 101804 NT 4
mac 101804 Mac OS9
Setting bug to Verified and removing vtrunk keyword
Status: RESOLVED → VERIFIED
Keywords: vtrunk
*** Bug 57658 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: