94641 - 4.7 pref for Pinpoint addressing does not migrate correctly

Status: RESOLVED WONTFIX

Description

[yulian chang]

Address Book was not checked under Pinpoint Addressing in my 4.x prefs file.
After migration, Local Address book was checked under Address Autocompletion.
 
Steps:

1. In Communicator, launch Preferences/Mail&Newsgroups/Addressing window
2. Check Address Books under Pinpoint Addressing and save it
3. Do clean installation of N6.1 and migrate the profile with above settings
4. In N6.1, launch Preferences/Mail&Newsgroups/Addressing window

actual result: Local Address books is checked under Address Autocompletion

Expected result:  Local Address books shouldn't be checked under Address
Autocompletion

Comment 1

[scottputterman]

reassigning to cavin

Comment 2

[Ninoschka Baca]

Marking nsbeta1. The workaround is easy, just deselect the Address
Collection|Local Address Book checkbox but migration should handle this case.

Comment 3

[Ninoschka Baca]

Changing summary from "Address Book prefs wasn't correctly migrated" to "4.7
pref for Pinpoint addressing does not migrate correctly".

Comment 4

[(not reading, please use [e-mail] instead)]

taking, fix in hand.  fixed as part of the AB_OUTLINER_BRANCH.

Comment 5

[(not reading, please use [e-mail] instead)]

this bug should be XP.

Comment 6

[(not reading, please use [e-mail] instead)]

Created attachment 62032 [details] [diff] [review]
patch, please review.

Comment 7

[(not reading, please use [e-mail] instead)]

the problem is we chose a new pref name, instead of the old 4.x pref name.
see #37955 (may 2000)

two ways to go about fixing this:

1) fix the added .js, .xul and default pref (in mailnews.js) to be how it was 
in 4.x: "ldap_2.autoComplete.useAddressBooks", and write code to fix existing 
users 6.x prefs.

2) add migration code for 4.x to 6.x, and leave existing 6.x users prefs 
alone.  

this patch does #2.

Comment 8

[David :Bienvenu]

Comment on attachment 62032 [details] [diff] [review]
patch, please review.

sr=bienvenu

Comment 9

[Cavin Song]

Comment on attachment 62032 [details] [diff] [review]
patch, please review.

r=cavin.

Comment 10

[(not reading, please use [e-mail] instead)]

fixed.

Comment 11

[Ninoschka Baca]

Trunk build 2002-02-01-03: WinMe
Trunk build 2002-02-01-08: Linux RH 7.1
Reopen, still a problem. Haven't checked mac yet.

Comment 12

[(not reading, please use [e-mail] instead)]

Created attachment 67975 [details] [diff] [review]
define default for 4.x pref in mailnews.js (in 4.x, this value lived in all.js)

Comment 13

[(not reading, please use [e-mail] instead)]

looking at the code, the lack of a default should not have caused the problem.

if the default was true, it that would mean the pref wouldn't be there,
so this code (if hit) would do nothing.  that's ok, since the default in 
mozilla is also true.

I'm wondering if this code isn't getting hit for some reason (news migration 
failure, causes us to bail early?)

Comment 14

[(not reading, please use [e-mail] instead)]

Created attachment 67982 [details] [diff] [review]
partial patch

a partial patch.  I think this is going to be a news migration issue.  I'll
ping for reviews once I get a complete patch.

Comment 15

[(not reading, please use [e-mail] instead)]

ok, I see what's going on.

if I migrate, but launch mail (or addressbook) before checking your prefs, it 
works.  the messenger migrator code gets run the first time you do any thing 
mail related.

if I migrate, and check prefs (from the browser), before I do anything mail 
related, it won't get migrated.

this isn't normally an issue because most mailnews pref migration affects the 
account manager, which can only be reached from the 3 pane.

one exception to this is the addressbook prefs, which are visible from the 
prefs and can be reached from the prefs.  note, there is some necessary ldap 
autocomplete pref migration that nsMessengerMigrator.cpp is doing.  I think 
there might be some other ldap autocomplete migration code else where, too.

I think the fix for this will be to:

1)  move all the ldap autocomplete migration code to nsMessengerMigrator.cpp
2)  add the js code to the mailnews pref overlays to check if need to 
migrateand if necessary perform migration when loaded.

Comment 16

[(not reading, please use [e-mail] instead)]

I discussed this with srilatha over aim.

There is code that does ldap / pref migration code
Its in nsLdapPrefsservice.js in mailnews/addrbook/src

the addressbook migration code in nsMessengerMigrator.cpp just migrates 
the "autcomplete against local addressbooks" pref (see 
http://bugzilla.mozilla.org/attachment.cgi?id=62032&action=view) and, if you've 
got an ab upgrader (only NS 6.x build have this), we'll migrate the local 4.x 
na2 files to .mab files.

there is other code that converts some ldap_2.* prefs into UTF-8.  see 
nsPrefMigration.cpp

we can't just move the ldap migration code from nsLdapPrefService.js to 
nsMessengerMigrator.cpp, because that code is need to migrate users from 
Netscape 6.0 (and mozilla 0.9.something) to modern builds, not just from 4.x to 
modern builds.

so, I think the proper solution for this bug is to do this:
leave the nsLdapPrefsService.js code alone.
leave the nsPrefMigration.cpp code alone
leave the nsMessengerMigrator.cpp code alone
add some code to the mailnews pref overlay js to call the upgrade code in 
nsMessengerMigrator.

we should treat prefs like a mailnews window (but only if mailnews is 
installed), and force migration of prefs when the window comes up.

the fix for this will look like this code:
http://lxr.mozilla.org/mozilla/source/mailnews/base/prefs/resources/content/acco
untUtils.js#150

since she owns migration, I'm going to hand this over to srilatha to fix.  I'll 
land the "partial patch" (which defines the 4.x default) for completeness, but 
it will not affect fix this problem.

srilatha, can you log a new bug about moving the migration code from 
nsLdapPrefsService.js into nsMessengerMigrator.cpp?  note, we can only do that 
work once we don't think people will be migrating from 6.0 to modern builds.  
until then, the code needs to stay where it is. 

Comment 17

[(not reading, please use [e-mail] instead)]

I've checked in the default pref.

since srilatha owns migration, she's the right owner for this.

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 25

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 26

[Karsten Düsterloh]

By courtesy of MXR, this seems still an issue.

Comment 27

[Magnus Melin [:mkmelin]]

4x migration is dead since some years ago