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.

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.

reassigning to chuang.

tonyr owns the address book import. Cc Ben since he touched the import skin code last week.

This appears to be a XP filepicker problem. Probably something I merged incorrectly. Taking.

PDT agrees with P1 priority.

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. ***

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.

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

Vera: release note

PDT marking [rtm need info] because we'd like to have a fix for this, after patch and code reviews are lined up.

*** 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.

Ben, get this puppy reviewed and approved.

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

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.

fix checked in to branch and trunk. Thanks, alec, seth and scott!

Marking fixed per ben's landing comment.

Verified in today's BRANCH builds on all platform!

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

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