My prefs.js file is growing slowly larger, with a triple of preferences being repeatedly added: ldap_2.servers.user_directory_1.filename = user_directory_1.mab ldap_2.servers.user_directory_1.replication.lastChangeNumber = 0 ldap_2.servers.user_directory_1.uri = moz-abldapdirectory://user_directory_1.mab Each set is incrementing the "_1" suffix (in both names and values). I'm not sure what action is triggering the addition of another set of these preferences; it's something more than simply causing a lookup (either one that matches or one that doesn't match entries in my address book). None of these .mab files exist on my disk. I have each account set to "Use my global LDAP server preferences". My global setting for LDAP is (I believe) OFF: Prefs|Mail|Addressing|Addr.Autocomplete []Directory Server is unchecked (and nothing is in the dropdown) I also have auto-collect turned off, if that applies to anything. Since I haven't been able to figure what triggers this, I'm not sure which version of Mozilla is causing it. When I installed 1.5 as my "usual" Mozilla, I deleted these preferences; since then, I have used 1.5, and various 1.6 and 1.7 builds -- and I just deleted another 15 sets of those preferences.

Recently I have noticed the same thing. I have the same settings as the reporter. If I delete all these entries, Mozilla 1.6 and 1.7a will recreate them. At least 61 entries for me. Sometimes the number will increase. I guess it has something to do with this code (generates prefs): http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/src/nsDirPrefs.cpp#2865 Perhaps component should be Address Book?

I had to reset my profile with an 1.8a build and used my original adress book. I deleted all - 121! (6x20 +1) - entries in my prefs.js. Now I have 21 entries again in it. Hmm ... I have 20 lists in my PAB, so 20 + 1 (root in PAB left-side view, I see all the lists in the tree). I guess it has something to do with the lists, and if you change/edit a list or something else it will add new entries to the prefs.js.

ditto I have about 400 ldap_2 entries in prefs.js moz 1.7 20040226 on windows 2000 200 in XP home Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041104

(In reply to comment #2) > Now I have 21 entries > again in it. Hmm ... I have 20 lists in my PAB, so 20 + 1 (root in PAB left-side > view, I see all the lists in the tree). I guess it has something to do with the > lists, and if you change/edit a list or something else it will add new entries > to the prefs.js. After some time and adding/removing cards from mailing lists (but no new list or so) I have 101 (50x2+1) entries (3 lines) again in prefs.js.

I don't see these entries in Seamonkey. But perhaps I haven't made a change that triggers the extra entries

Thanks for the reminder -- I just deleted all the related prefs from my TB prefs.js, and I'll check it after a couple weeks to see if they've returned.

(In reply to comment #6) > Thanks for the reminder -- I just deleted all the related prefs from my TB > prefs.js, and I'll check it after a couple weeks to see if they've returned. OK: Twelve days later, I check and see that I have two sets of the preferences now in my file: user_directory_1 and user_directory_2. These are still being created mysteriously in the background, for no good reason.

(In reply to comment #7) > (In reply to comment #6) > OK: Twelve days later, I check and see that I have two sets of the preferences > now in my file: user_directory_1 and user_directory_2. These are still being > created mysteriously in the background, for no good reason. Mike, yes I think I'm still seeing this problem as well. Just a couple of possibly obvious questions, but some that may help: Did you create/delete any address books during this period? Do you use any ldap directories? Do you have any ldap_1 preferences listed in your prefs.js? Thanks.

(In reply to comment #8) > Did you create/delete any address books during this period? No. > Do you use any ldap directories? No, other than the Address Book. The preferences from comment 0 are still set the same way. > Do you have any ldap_1 preferences listed in your prefs.js? Yes: ldap_1.directory1.description = Personal Address Book ldap_1.directory1.dirType = 2 ldap_1.directory1.isOffline = false ldap_1.directory2.description = Four11 Directory ldap_1.directory2.serverName = ldap.four11.com [three more pairs like 'directory2' for Infospace, WhoWhere and Bigfoot] ldap_1.directory6.description = Switchboard Directory ldap_1.directory6.serverName = ldap.switchboard.com ldap_1.directory6.searchBase = c=US ldap_1.directory6.filter1.repeatFilterForWords = false ldap_1.directory6.attributes.telephoneNumber = Phone Number:homephone ldap_1.directory6.attributes.street = State:st I also see ldap_2 prefs similar to the above, of a different form: ldap_2.servers.four11.description = Four11 Directory ldap_2.servers.four11.serverName = ldap.four11.com ldap_2.servers.four11.position = 0 [and similar for Bigfoot, Switchboard, WhoWhere]

Ok, I think I've found the problem. Turns out its an core address book bug and not a ldap integration on, patch coming up soon...

I'm not 100% sure that this patch will fix the bug. What I did find was that when the address book is sorting the directory tree it attempts to get directory properties for Mailing Lists as well as normal directories. As Mailing Lists don't have preferences, this was causing the dir_CreateServerPrefName to be called in nsDirPrefs which would have no prefName supplied and end up returning a user_directory_<n> value. However, testing with the patch removed shows that the problem doesn't appear to normally create the user_directory_<n> preferences in prefs.js. So I'm not convinced the patch will do the job. However the code is wrong - for a mailing list it shouldn't be (and doesn't need to) getting directory properties, so I'm submitting it anyway as it is still a good tidy up.

Comment on attachment 212327 [details] [diff] [review] Possible fix (checked in trunk, branch & 1.8.0.x branch) I've just checked this in so it should be in builds started after this date/time. As I'm not 100% sure that this will fix this bug, I'll leave it open for a couple of weeks and if people can keep an eye on their prefs files then that would be very useful (Thanks in advance).

I appreciate the patch, but I cannot commit for even two days to using only a trunk build, so I can't reliably test this.

I was unable to recreate the problem with TB 1.5. Which entries are save to delete? all ldap_2.servers.user_d* ?

(In reply to comment #14) > I was unable to recreate the problem with TB 1.5. Its not an easy one to recreate... I've tried various things in the past and not been able to reproduce them. > > Which entries are save to delete? all ldap_2.servers.user_d* ? > As long as they haven't got .description or .dirType items you should be ok. Mine consist of just .filename, .replication.lastChangeNumber and .uri. Of course, you should perhaps back up prefs.js first ;-)

try this: inventory ldap_2.servers.user_d* create a new list, eg "X1" add one email address that does not exist in ldap or address book, eg "1X" OK inventory ldap_2.servers.user_d* for me it added 5 sets of 3 ldap_2.servers.user_d* I could not replicate on second attempt

I'm not sure where this has come from, but I just looked into my options to delete these accumulated prefs and noticed a similar but new symptom: I'm now seeing triples of preferences, as described in comment 0, except with different names: ldap_2.servers._nonascii_1.filename ldap_2.servers._nonascii_1.replication.lastChangeNumber ldap_2.servers._nonascii_1.uri I've got ten of these triples in place, as well as two sets with the original 'user_directory_N' names.

(In reply to comment #17) > I'm not sure where this has come from, but I just looked into my options to > delete these accumulated prefs and noticed a similar but new symptom: I'm now > seeing triples of preferences, as described in comment 0, except with different > names: > ldap_2.servers._nonascii_1.filename > ldap_2.servers._nonascii_1.replication.lastChangeNumber > ldap_2.servers._nonascii_1.uri > I've got ten of these triples in place, as well as two sets with the original > 'user_directory_N' names. > The _nonascii_ is a new item introduced recently to cover address book names consisting of entirely non-ascii characters. This helps usage under different locales. I forget which bug it is. I think the change went into all trunk & current 1.8.x branches, but could you just confirm which version you're seeing this on?

(In reply to comment #18) > I think the change went into all trunk & current 1.8.x branches, but could you > just confirm which version you're seeing this on? I can't say specifically. I am frequently running builds from the branch (2a1) and the trunk (3a1) as well as 1.5.0.2, depending on what I'm testing. The most recent versions of these programs I've been running are 2a1-0416 and 3a1-0426. And of course, the only time I'm actually aware of the bug is when I think to look in prefs in the first place, so these changes could have occurred any time since I last deleted the accumulated prefs -- which probably was around the time you submitted the patch. fwiw, none of my address books have a non-ASCII name. Whoever named those prefs is guilty of not seeing the forest for the trees.

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

Comment on attachment 212327 [details] [diff] [review] Possible fix (checked in trunk, branch & 1.8.0.x branch) This has been on the trunk for a while now with no regressions pointed out. This may/may not be the full fix, its hard to tell at the moment and I think exposing on branch wouldn't cause any harm and could potentially give us a better indication.

i'd like only to point that there are already 3 cases in which this bug has caused thunderbird not to open (it opens after a long time, minutes). I had about 1500 entries (it took about 1 minute to load) while another user posted 2800 entries. The problem appear on the address book but installing "contact sidebar" extension (and this case is real common) thunderbird hangs at startup and does not respond for that time... this slows down the startup and maybe it will cause people to think that TB is slow while it's a profile bug... So please move the fix to branch, i have to clean the prefs.js continuously sorry for my english and thanks :)

(In reply to comment #22) > So please move the fix to branch, i have to clean the prefs.js continuously > sorry for my english and thanks :) The *possible* fix has already been copied to the branch ready for the 2.0 releases. I'm not going to propose copying it to the 1.5 branch as at the moment we don't know if it fixes the problem or not.

(In reply to comment #17) > ldap_2.servers._nonascii_1.uri Mike, what data is placed in the entry? Isn't it URI like "moz-abldapdirectory://_nonascii_1.mab"? Or null? (for usual address book)

(In reply to comment #18) > The _nonascii_ is a new item introduced recently to cover address book names > consisting of entirely non-ascii characters. You are right. Who introduced string of "nonascii" is fix for Bug 316812. > I think the change went into all trunk & current 1.8.x branches, but could you > just confirm which version you're seeing this on? You are wrong. Bug 316812 is already applied to 1.5.0.2 and 1.8.1 branch and trunk. (In reply to comment #19) > Whoever named those prefs is guilty of not seeing the forest for the trees. No. Bug 316812, which resolved problem after Bug 239714, simply changed entry name (which is related to this bug) from user_directory or user_directory_N to _nonascii or _nonascii_N. Difference of this bug's phenomenon before and after Bug 316812 is : (Before) Bug 239714 fixed but Bug 316812 remains(Tb 1.0.x & Tb 1.5.0.0/1.5.0.1) Since Bug 316812 is not fixed, user_directory and many user_directory_N's are overlayed when Thunderbird is restarted. (1) user_directory is created and user_directory_1, user_directory_2,... are created. (phonomen of your comment #0) (2) When restarted, entry name of user_directory is overlayed, and user_directory_1, user_directory_2,... are also overlayed. (After) Bug 239714 fixed and Bug 316812 is fixed(Tb 1.5.0.2 or after) (1) _nonascii_ is created and _nonascii_1, _nonascii_2,... are created. (same as your comment #0 except entry name) (2) When restarted, new entries are created because Bug 316812 resolved entry overlay problem, and user_directory_(N+1), user_directory_(N+2) are generated by this bug's problem, then number of entries will continue to increase until limitaion of N for _nonascii_N is reached. I suspect mismatch between spec/design/current coding of DIR_CreateServerPrefName in nsDirPrefs.cpp and pref creation/prefname request/pref deletion logic in LDAP server access (looks to be created when replicattion or re-synchronization). Removing "fixed1.8.1" from keyword: field.

Oh sorry, Marks's patch is already landed to 1.8.1 and trunk. Putting fixed1.8.1 again. Sorry for spam. Mike Cowperthwaite, did you verify that problem was fixed by mark's patch? "Long time to open address book" problem is sometimes reported to forums, and has been reported to a forum in Japan, and phenomenon of this bug is always seen in comments in forums. So I'd like to know whether this bug is already verified or not.

(In reply to comment #26) > Mike Cowperthwaite, did you verify that problem was fixed by mark's patch? > "Long time to open address book" problem is sometimes reported to forums, and > has been reported to a forum in Japan, and phenomenon of this bug is always > seen in comments in forums. So I'd like to know whether this bug is already > verified or not. See comment 19 on this bug - Mike uses a selection of builds and so hasn't been able to verify it. I on the other hand keep on forgetting to check my dev profiles.

I last deleted the accumulated user_directory and _nonascii_ prefs on 01-May, but I was away from my computer for ten days shortly after that. I have occasionally run 1.5 in the interim, but mostly I'm running 3a1 or 2a1 builds; currently, there are no new instances of these prefs. The only user actions I can think of that might trigger the generation of these prefs would be: using autocomplete for address lookups while composing; opening or editing the address book; or changing the LDAP prefs. The first of these I've done at least a couple times using 1.5, and quite a few more times with 2a1/3a1; I'm not sure if I've done anything with the Address Book in that period, let alone which version; the LDAP prefs I've not even looked at. OT: (In reply to comment #25) > (In reply to comment #19) > > Whoever named those prefs is guilty of not seeing the forest for the trees. > > No. Yes. The preference name ldap_2.servers._nonascii_1.filename is much less descriptive than the original ldap_2.servers.user_directory_1.filename The fact of the servername's non-ASCII-ness should be entirely transparent; there is no need to be naming the preference after it. An analogy would be naming the wrap-column preference mailnews.integervalue But names of preferences are pretty arbitrary for the most part anyway, more's the pity.

(In reply to comment #28) > The preference name > ldap_2.servers._nonascii_1.filename > is much less descriptive than the original > ldap_2.servers.user_directory_1.filename I didn't care on fallback leafname, can accept any leafname since Tb 1,0, because address book name of "+1" and "++1" always produce leafname of "1" then entry name becomes ldap_2.servers.1_NNN.filename. This is always true for address book name of "<Any_Japanese_Chars>1". This was introduced by Bug 239714 when Tb 1.0 RC1. But I now agree with you on "much less descriptive than the original". When patch for Bug 316812 is created, I was convinced that something which includes LDAP server related string is passed for LDAP server entry. I was convinced that fallback to "_nonascii_" occurs only when whole name is non-ascii, then I was not oposite to fallback name change. But it seems to be wrong. When LDAP server, null is possibly passed as seed for leafname. Mike, could you open bug for "Non descriptive entry name problem when LDAP server"?

(In addition to comment #29) leafname is determined by following logic in DIR_CreateServerPrefName of nsDirPrefs.cpp. + if (name) + leafName = nsCRT::strdup(name); + else + leafName = dir_ConvertDescriptionToPrefName (server); + if (!leafName || !*leafName) { leafName = nsCRT::strdup("_nonascii"); } (Duplication check logic follows) When usual address book, name or server is passed, but when this bug's entry case, null as server seems to be passed to this logic. Since dir_ConvertDescriptionToPrefName(server) exists, I was convinced that LDAP server name related value is usually passed as server parameter. But it seems to be wrong. If null value for server parameter is the reason, I think change to following logic will change leafname back to "user_directry_NNN" and will resolve "less descriptive issue" on entries related to this bug. > if (name) leafName = nsCRT::strdup(name); > else if (server) leafName = dir_ConvertDescriptionToPrefName(server); > else leafName=nsCRT::strdup("user_directry"); If no alpha-numeric in non-null server parameter value is the reason, above logic will still produce "_nonascii_". Sorry but I don't know which.

(Correction of comment #30) DIR_CreateServerPrefName of nsDirPrefs.cpp is called by DIR_SetServerFileName of nsDirPrefs.cpp. And an example of call of DIR_SetServerFileName is: (looks to be replicator) http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/src/nsAbLDAPReplicationQuery.cpp#93 93 DIR_Server* server = DIR_GetServerFromList(mDirPrefName.get()); 94 if (server) 95 { 96 DIR_SetServerFileName(server); 97 // Now ensure the prefs are saved 98 DIR_SavePrefsForOneServer(server); 99 } In this case, server can not be null. So "non-ASCII-ness" when LDAP server is possibly binary data such as pointer or binary IP address instead of string data such as server name. I think following is simpelest and easiest way. Simply change fallback-leafname back to "user_directory".

i have copied my profile to a new windows xp account to do some testing. test 1 ====== launch TB 1.5, open address book, close address book, close TB 1.5 result: prefs.js grows about 20KB test 2 ====== launch TB 2.0a1 (22/05/2006 build), , open address book, close address book, close TB 1.5 result: prefs.js does not grow, all ok So the patch is working, but each of them (1.5 and 2.0) suffer of SLOW starting time if prefs.js is not clean... so i think that TB2.0 should check and clean non existant references in prefs.js cause updating TB will mantain all pending references nad the slow startup...

> I think following is simpelest and easiest way. > Simply change fallback-leafname back to "user_directory". Please feel free to put a patch for that on a new bug. (In reply to comment #32) > So the patch is working, but each of them (1.5 and 2.0) suffer of SLOW starting > time if prefs.js is not clean... so i think that TB2.0 should check and clean > non existant references in prefs.js cause updating TB will mantain all pending > references nad the slow startup... I'm not sure about this. I'd firstly need to check what prefs are normally written (I can't do that at this moment in time) to see if it is really possible (I suspect it would be). However, if a user tried to modify their setup and got it wrong, we could potentially erase all definitions of that ab from thier prefs which would be annoying as well. I'm also soon hoping to start work on a new address book backend system that would in theory automatically remove these redundant prefs. Finally, I'm not sure if yours is the only test case to reproduce the bug - especially as others haven't been able to reproduce it that easily. Therefore I'd rather leave removing the redundant prefs till later so we can track if it is still happening or not. In the meantime, we could possibly put out information on the release notes on how to fix the problem.

When report to Bugzulla Japan by a user in Japan, next triplets were found. (A) _nonascii.filename/replication.lastChangeNumber/uri (No number suffix) (B) _nonascii_N.filename/replication.lastChangeNumber/uri (N=1 to 2824) (C) user_directory_M.filename/replication.lastChangeNumber/uri (M=1 ro 144) Note: (A) and (B) is one created by Tb 1.5.0.2 or after. (C) is one created by Tb 1.0.x or Tb 1.5.0.0/1.5.0.1. Total of 8907==3*(1+2824+144) is to be removed... Manual removing by text editor is simple and easy operation, but error prown. So I created PHP script(batch) to remove. (PHP can be used by decompress only)

Following problem of initial version of PHP script is resolved. Triplets for valid entry is removed, if the triplets has same data as garbages by this bug. This can occur when valid LDAP server entry is created by Tb 1.5.0.1 or before, or when valid LDAP server entry for really non-ascii name is created by Tb 1.5.0.2 or later. Sorry for spam.

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

(In reply to comment #23) > I'm not going to propose copying it to the 1.5 branch as at the > moment we don't know if it fixes the problem or not. Some comment posters of MozillaZine forum say that they aren't experiencing problem after your patch. http://forums.mozillazine.org/viewtopic.php?t=400888&postdays=0&postorder=asc&postsperpage=15&start=30 Mark Banner, I think problem is resolved by your patch and I believe that your patch is sufficiently baked.

Comment on attachment 212327 [details] [diff] [review] Possible fix (checked in trunk, branch & 1.8.0.x branch) Requesting approval for 1.8.0.x branch. This patch stops Thunderbird and SeaMonkey from increasing the size of prefs.js unnecessarily. The increase of size in prefs.js causes a slow down when doing autocomplete searches and opening up the address book. It doesn't remove the redundant entries, but will at least stop it getting any worse. It has been on trunk and the 1.8 branch for quite a while now and it'd be worth bringing it across to the 1.8.0.x support branch.

Well, fixing bugs for future versions is good, but how about fixing current releases! The Problem ist still existing in current TB 1.5.0.5 (1.8.0.x branch)! How get effectively rid of those entries? Releasing a Patch based on PHP is fine, but makes it necessary to install PHP on each computer. This isn't a real solution for large environments. Furthermore it doesn't fix the problem itself.

(In reply to comment #39) > The Problem ist still existing in current TB 1.5.0.5 (1.8.0.x branch)! ... > Furthermore it doesn't fix the problem itself. Try reading my previous comments on this bug. We are currently waiting approval for the fix for the 1.8.0.x branch which will stop creating the entries (see my previous comments on the bug). > How get effectively rid of those entries? > Releasing a Patch based on PHP is fine, but makes it necessary to install PHP > on each computer. This isn't a real solution for large environments. The problem of the creation is fixed by the first patch on this bug. Nothing has been done about being able to remove the entries automatically as I haven't had time due to family commitments and I don't get paid to work on this. No one else has submitted a patch either. So please do feel free to submit a patch that will remove the redundant entires automatically in the address book code.

Comment on attachment 212327 [details] [diff] [review] Possible fix (checked in trunk, branch & 1.8.0.x branch) Changing approval request back to 1.8.0.8 - where I had originally requested this patch for. See comment 38 for my previous approval request notes.

Mark, did we ever figure out if Scott's issue where he lost the use of his personal ab was possibly related to this change? I can't remember how that issue resolved itself, if it did...

(In reply to comment #42) > Mark, did we ever figure out if Scott's issue where he lost the use of his > personal ab was possibly related to this change? I can't remember how that > issue resolved itself, if it did... > David, you're thinking of two other issues. I'll let you know which ones over irc...

Comment on attachment 212327 [details] [diff] [review] Possible fix (checked in trunk, branch & 1.8.0.x branch) approved for 1.8.0 branch, a=dveditz... please land this week or it may get bumped to 1.8.0.9 (which is the next "stability" release anyway, 1.8.0.8 is for FF2-parity for security fixes).

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

Mark, shouldn't you mark this fixed now?

If you mark it fixed, is the fix available now to users? After reading the comments, I do not have a clear idea as to how the "FIX" can be implemented if I've read the comments correctly. prefs.js has grown to 120,380 bytes and continues. You may look back at Bug 356757 to see a growth table over time. If it is fixed in 1.8.0.8, when might us mortals see it available?

I'm running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061017 Thunderbird/2.0b1pre ID:2006101707 , and I still see the bug. I still have to try it in a fresh profile.

This bug is fixed - the entries will no longer be created. Old entries however, will *not* be removed - they have to be removed by hand. The bug to implement automatic removal is bug 357008 and help is wanted on that. The patch for this bug will be incorporated into the next release of Thunderbird 1.5.0.x and SeaMonkey 1.0.x when they happen (I believe sometime after FF2 is out, though I don't know for sure). It should already be in the current nightly builds for Thunderbird (2.0 beta) and SeaMonkey (1.1 beta). It will also be in the current trunk builds for Thunderbird (3.0a1) and SeaMonkey (1.5a).

I guess I should clarify what I stated about still seeing the bug in the latest TB2 build. I closed TB, removed the user_pref("ldap_2.servers._nonascii. entries from my prefs.js, and loaded TB. I opened the address book window, clicked on each one of my address books, and closed TB. I looked in the prefs.js, and there are new entires: user_pref("ldap_2.servers._nonascii.filename", "_nonascii.mab"); user_pref("ldap_2.servers._nonascii.replication.lastChangeNumber", 0); user_pref("ldap_2.servers._nonascii.uri", "moz-abldapdirectory://_nonascii.mab"); As I said, I still need to test it in a new profile; but marking this bug as fixed is making me speak up right now.

(In reply to comment #50) > I guess I should clarify what I stated about still seeing the bug in the latest > TB2 build. ... > As I said, I still need to test it in a new profile; but marking this bug as > fixed is making me speak up right now. Thanks for making that clear Chris. I've been using SeaMonkey on branch with that fix for quite a while now and not suffered with any problems. The back-end code is very similar, so I'd be surprised if its specific to TB. Additionally Wayne tells me he's had no problems with a trunk TB build. Its also the first I've heard of being able to reproduce it in that manner (I tried with Trunk SM and couldn't, my TB is out of date). So trying with a fresh profile would be useful feedback, especially if it turns out that a particular setting/address book is causing the problem. Of course it'd be really nice to check the bit of code where this could be happening. Are there any messages on the Error Console that may be helpful?

I think I found it. I created a new profile, and started adding possible variables. After adding: user_pref("ldap_2.servers.OE.description", "Outlook Express"); user_pref("ldap_2.servers.OE.dirType", 3); user_pref("ldap_2.servers.OE.uri", "moz-aboutlookdirectory://oe/"); to my prefs.js, I started TB, opened the address book window, closed TB. That's when the "_nonascii" lines appeared.

As reporter of this bug: I've been running almost exclusively in 2b1 and 3a1 builds for months, and since June I've tried to use a test profile when I need to go into a 1.5 or earlier version. I don't remember the last time I deleted these superfluous prefs, but it must be several weeks if not longer. I don't have any of those prefs in my config now, even after trying the click-on-address-book-and-exit from comment 50 (with 2b1-1014). I don't have an OE-imported address book; I might have when I opened this bug, but it's long gone and I've seen the reported symptoms in the interim. The patch from late May seems to have addressed my issue.

After reading Comment 53 I checked my prefs.js. NO Outlook references. NOTHING was ever imported for OE. I've never really used it. To the point. When 53 was read, my prefs.js was 120,380 - This was he highest entry -- user_pref("ldap_2.servers._nonascii_369.filename", "_nonascii_369.mab"); user_pref("ldap_2.servers._nonascii_369.replication.lastChangeNumber", 0); user_pref("ldap_2.servers._nonascii_369.uri", "moz-abldapdirectory://_nonascii_369.mab"); Tbird was started. Address book opened. "Names" clicked to sort in different order. Since this was not the order I wanted, "Names"was clicked to put it in ascending order. Address book closed. Tbird closed. Prefs.js checked for size - 124,477 and the highest entry -- user_pref("ldap_2.servers._nonascii_390.filename", "_nonascii_390.mab"); user_pref("ldap_2.servers._nonascii_390.replication.lastChangeNumber", 0); user_pref("ldap_2.servers._nonascii_390.uri", "moz-abldapdirectory://_nonascii_390.mab"); Because I did not keep good notes, I did the following. Prefs.js was 124,477 when this process was started. Tbrid opened. Address Book Opened "Main Book clicked" Closed address book Closed TB NOTHING ELSE WAS DONE. Prefs.js now - 128,574 and the lighest entry - user_pref("ldap_2.servers._nonascii_407.filename", "_nonascii_407.mab"); user_pref("ldap_2.servers._nonascii_407.replication.lastChangeNumber", 0); user_pref("ldap_2.servers._nonascii_407.uri", "moz-abldapdirectory://_nonascii_407.mab"); Any other tests or exercises to perform? Tbird - version 1.5.0.7 (20060909) I've got 1 profile, the original default and 9 accounts. Hope this helps.

The fix is not in Thunderbird 1.5.0.7. You should see it in 1.5.0.8 (when 1.5.0.8 is released).

Where does version 3 alpha 1 (20061017) fit in the scheme of things? I'll try this to see the effects.

(In reply to comment #56) > Where does version 3 alpha 1 (20061017) fit in the scheme of things? See <http://forums.mozillazine.org/viewtopic.php?t=388559>. > I'll try this to see the effects. If you don't know what TB3 is, you're probably better off testing this bug in the latest 1.5.0.x nightly. <http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8.0/>

Test Results Prefs.js was cleaned out and brought back down to 30.8 Kb. The procedures used to demonstrate the size increase were used with the address book as mentioned in comment 54. This was done a couple of times. However, the second time around Tbird crashed. A log file was created. The version information from the crash window -- AppName: thunderbird.exe AppVer: 1.9.20061.1704 ModName: unknown ModVer: 0.0.0.0 Offset: 051eaca0 Because of the crasah, the address book was opened, and sorted to make sure the prefs.js file was written back after use. I assume it was not when Tbird crashed. However, since this version has some stability issues, I'll go back to the latest released version and live with the growing prefs.js file until 1.8... is released. I rather have a growing prefs file than a version that crashes.

(In reply to comment #52) > I think I found it. > I created a new profile, and started adding possible variables. After adding: > user_pref("ldap_2.servers.OE.description", "Outlook Express"); > user_pref("ldap_2.servers.OE.dirType", 3); > user_pref("ldap_2.servers.OE.uri", "moz-aboutlookdirectory://oe/"); > to my prefs.js, I started TB, opened the address book window, closed TB. That's > when the "_nonascii" lines appeared. Ok, thanks Chris that's useful. A couple of extra tests would be useful if possible please: Can you tell me if this scenario happens on a Trunk build as well? There's been some significant changes to the prefs backend on trunk since branch happened. Also with the branch build, what happens if you add in the following pref to prefs.js alongside your list above and then try the scenario again: user_pref("ldap_2.servers.OE.filename", "temp.out"); As far as I know the outlook part of the code doesn't actually require a filename, but I suspect that nsDirPrefs.cpp may be expecting one when it shouldn't - and other things may be wrong which is causing the creation of the entries when it shouldn't be.

Just installed version 2 beta 1 (20061017), thunderbird-2.0b1pre.en-US.win32.installer.exe It does NOT have the problem with prefs.js growing. The existing entries containing any "ldap" entries are -- user_pref("ldap_2.prefs_migrated", true); user_pref("ldap_2.servers._nonascii.filename", "_nonascii.mab"); user_pref("ldap_2.servers._nonascii.replication.lastChangeNumber", 0); user_pref("ldap_2.servers._nonascii.uri", "moz-abldapdirectory://_nonascii.mab"); user_pref("ldap_2.servers.ab030904.description", "MainBook"); user_pref("ldap_2.servers.ab030904.dirType", 2); user_pref("ldap_2.servers.ab030904.filename", "impab.mab"); user_pref("ldap_2.servers.ab030904.isOffline", false); user_pref("ldap_2.servers.ab030904.maxHits", 0); user_pref("ldap_2.servers.ab030904.position", 3); user_pref("ldap_2.servers.ab030904.replication.lastChangeNumber", 0); user_pref("ldap_2.servers.default.filename", "default.mab"); user_pref("ldap_2.servers.default.replication.lastChangeNumber", 0); user_pref("ldap_2.servers.default.uri", "moz-abldapdirectory://default.mab"); user_pref("ldap_2.servers.history.replication.lastChangeNumber", 0); user_pref("ldap_2.servers.pab.replication.lastChangeNumber", 0); user_pref("ldap_2.servers.testbook.position", 0); This will grow using the current released version. It does NOT grow using version 2 beta 1 (20061017), thunderbird-2.0b1pre.en-US.win32.installer.exe If there are any changes or other issues, they will be posted. At this point, the plan is to continue to use version 2 beta 1 (20061017).

(In reply to comment #59) > Can you tell me if this scenario happens on a Trunk build as well? There's been > some significant changes to the prefs backend on trunk since branch happened. Doesn't happen on the latest trunk. (2006101806) > Also with the branch build, what happens if you add in the following pref to > prefs.js alongside your list above and then try the scenario again: > > user_pref("ldap_2.servers.OE.filename", "temp.out"); Still happens on the 1.8 branch. Even when I create a new profile (no previous OE prefs).

(In reply to comment #61) > (In reply to comment #59) > > Can you tell me if this scenario happens on a Trunk build as well? There's been > > some significant changes to the prefs backend on trunk since branch happened. > > Doesn't happen on the latest trunk. (2006101806) This is marked as a trunk build bug. ???

(In reply to comment #62) > (In reply to comment #61) > > (In reply to comment #59) > > > Can you tell me if this scenario happens on a Trunk build as well? There's been > > > some significant changes to the prefs backend on trunk since branch happened. > > > > Doesn't happen on the latest trunk. (2006101806) > This is marked as a trunk build bug. ??? Yes, this bug used to happen on trunk and all branches. It now appears we've sorted out trunk and one part of branch but there's one other particular case on branch we're looking at as well.

Verified bug with Win XP Pro / TB 1.5.0.7 I found almost 2000 lines like the following one in my "prefs.js": user_pref("ldap_2.servers._nonascii_XXXX.uri", "moz-abldapdirectory://_nonascii_XXXX.mab"); (XXXX is was a number between 1 and 1959). Adress book and adress-auto-complete were very slow. After manually deleting the lines, everything seems to be fine, again.

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

This bug appears to still exist in the [Windows] version of 1.5.0.8 (assuming that is what the "fixed in 1.8.0.x" really means). After manually deleting all the bogus server._nonascii__ lines (over 5050) that were in my prefs.js file, new ones are coming back. Unfortunately, I can't reopen the bug...

(In reply to comment #66) > This bug appears to still exist in the [Windows] version of 1.5.0.8 (assuming > that is what the "fixed in 1.8.0.x" really means). After manually deleting all > the bogus server._nonascii__ lines (over 5050) that were in my prefs.js file, > new ones are coming back. > > Unfortunately, I can't reopen the bug... > Have you defined an outlook address book as one of your books?

(In reply to comment #67) > (In reply to comment #66) > > This bug appears to still exist in the [Windows] version of 1.5.0.8 (assuming > > that is what the "fixed in 1.8.0.x" really means). After manually deleting all > > the bogus server._nonascii__ lines (over 5050) that were in my prefs.js file, > > new ones are coming back. > > > > Unfortunately, I can't reopen the bug... > > > Have you defined an outlook address book as one of your books? No, I have all my LDAP servers set to None. Sorry, I posted the comment for the wrong bug, they apply to the related bug 357008 -- so my statement about this bug not being fixed in v1.5.0.8 does not apply.

(In reply to comment #68) > (In reply to comment #67) > > (In reply to comment #66) > > > This bug appears to still exist in the [Windows] version of 1.5.0.8 (assuming > > > that is what the "fixed in 1.8.0.x" really means). After manually deleting all > > > the bogus server._nonascii_ lines (over 5050) that were in my prefs.js file, > > > new ones are coming back. > > > > > > Unfortunately, I can't reopen the bug... > > > > > Have you defined an outlook address book as one of your books? > > No, I have all my LDAP servers set to None. > > Sorry, I posted the comment for the wrong bug, they apply to the related bug > 357008 -- so my statement about this bug not being fixed in v1.5.0.8 does not > apply. > Darn it! OK, I now understand that the addition of "server._nonascii_" lines to the prefs.js file DOES apply to this bug after all. And that it being resolved "fixed in 1.8.0.x" means TB2 and therefore why it, or at least the _nonascii variation of the problem, is still present the 1.5.0.8. release. Whatever the fix was, it would be nice if it could somehow also be applied to a nearer term release while we're waiting for v 2.0...

For the last week or so, this bug has been absent in my Thunderbird v. 1.5.0.8 (20061025) This is very strange since I've had the problem constantely since I reported it early this summer. And I don't think that I have upgraded Thunderbird the past 2 weeks or so. Has anyone experienced the same?

For the last week or so, this bug has been absent in my Thunderbird v. 1.5.0.8 (20061025) This is very strange since I've had the problem constantely since I reported it early this summer. And I don't think that I have upgraded Thunderbird the past 2 weeks or so. Has anyone experienced the same?

(In reply to comment #71) > For the last week or so, this bug has been absent in my Thunderbird v. 1.5.0.8 > (20061025) > This is very strange since I've had the problem constantly since I reported it > early this summer. > And I don't think that I have upgraded Thunderbird the past 2 weeks or so. > > Has anyone experienced the same? > I am having the same experience. The problem seems to have disappeared. Hurray! (And thanks to whoever fixed it.)

(In reply to comment #72) > (In reply to comment #71) > > For the last week or so, this bug has been absent in my Thunderbird v. 1.5.0.8 > > (20061025) > > This is very strange since I've had the problem constantly since I reported it > > early this summer. > > And I don't think that I have upgraded Thunderbird the past 2 weeks or so. > > > > Has anyone experienced the same? > > > I am having the same experience. The problem seems to have disappeared. > Hurray! (And thanks to whoever fixed it.) > Hmmm, I've just switched to TB 2 beta 1, cleaned out prefs.js, restarted TB and opened the address book to look at a few entries, exited and found 12 sets of those spurious lines...

(In reply to comment #73) > Hmmm, I've just switched to TB 2 beta 1, cleaned out prefs.js, restarted TB and > opened the address book to look at a few entries, exited and found 12 sets of > those spurious lines... Are you using either of the outlook or outlook express address books within TB? Which OS are you using?

(In reply to comment #74) > (In reply to comment #73) > > Hmmm, I've just switched to TB 2 beta 1, cleaned out prefs.js, restarted TB and > > opened the address book to look at a few entries, exited and found 12 sets of > > those spurious lines... > Are you using either of the outlook or outlook express address books within TB? > Which OS are you using? Also, are you using any address book related extensions?

(In reply to comment #75) > (In reply to comment #74) > > (In reply to comment #73) > > > Hmmm, I've just switched to TB 2 beta 1, cleaned out prefs.js, restarted TB and > > > opened the address book to look at a few entries, exited and found 12 sets of > > > those spurious lines... Actually, did you close TB *before* cleaning out prefs.js? If you have TB open whilst editing prefs.js then TB will overwrite it on exit.

(In reply to comment #76) > (In reply to comment #75) > > (In reply to comment #74) > > > (In reply to comment #73) > > > > Hmmm, I've just switched to TB 2 beta 1, cleaned out prefs.js, restarted TB and > > > > opened the address book to look at a few entries, exited and found 12 sets of > > > > those spurious lines... > > Actually, did you close TB *before* cleaning out prefs.js? If you have TB open > whilst editing prefs.js then TB will overwrite it on exit. > Yes, TB was closed when I cleaned out prefs.js. > Are you using either of the outlook or outlook express address books within TB? Not as such, although I have imported the Windows address book. > Which OS are you using? Win XP Pro > Also, are you using any address book related extensions? Aha, that's it. I've got 'TB Change From and FCC on Compose" 0.3.8 with just the "Use Freeform Fcc" option enabled. Disabling the extension fixes things; re-enabling it results in the junk lines - it's quite reproducible. Thanks, Dave

I had a theory about this, having to do with a failure to open files due to some sort of file locking, but now I wonder about the extension theory. I had this happen to me when I ran 2.0 beta 1 and left it running unattended for a few hours. There's also code that creates servers by migrating the 4.x-style prefs. Does anyone this is happening to have a profile that was migrated from 4.x?

I'm unclear on how to reproduce this bug and, thus, how to verify it. Can someone who's seen it verify that it's been fixed in Tb2 nightlies?

i had big troubles with this on one installation (daily added prefs) and i can verify and confirm that this is fixed in tb2.0 final. There are no easy steps to reproduce, i had these: - installed tb 1.5 - imported everything from outlook express - added many contacts with accented and other non english charachters - prefs.js grow started

I'm going to go ahead and mark this as verified1.8.1.3 based on Marco's comments. Thanks for your help, Marco!

AFAICT this still happens when using Outlook (Express)'s address book directly from Thunderbird. Steps to reproduce: 1. Have Thunderbird 2.0 (final) use OE's address book (cf. http://kb.mozillazine.org/Using_Outlook_(Express)_contacts_with_Thunderbird_or_Mozilla_Mail ) 2. Open Tb's address book Every time you open Tb's address book, another tripple gets added. Undoing step 1 prevents the tripples. OE's and TB's address book can both be empty for it to work.

(In reply to comment #82) > AFAICT this still happens when using Outlook (Express)'s address book directly > from Thunderbird. As outlook isn't "standard" please raise this in a separate bug and we'll deal with it there.

(In reply to comment #83) > As outlook isn't "standard" please raise this in a separate bug Filed bug 378388 for the issue.

It still happens if the 'TB Change From and FCC on Compose" add-on is enabled - 15 spurious triples just from sending one email... As the add-on is not standard, I'm happy for this to be closed - is bug 378388 the place to note the add-on's behaviour? Or should a new bug be raised??

(In reply to comment #85) > > As the add-on is not standard, I'm happy for this to be closed - is bug 378388 > the place to note the add-on's behaviour? Or should a new bug be raised?? suggest file a new bug with the details

I'm unable to reproduce this bug in TB 3.0a1pre (2007091004). I am able to reproduce it in TB 2.0.0.6 (20070728), using the Javascript code below (distilled from the Change From+FCC add-on) or the add-on itself, in an otherwise-clean profile. Neither the snippet below nor the add-on seems to trigger the behavior in 3.0a1pre. I did all of the research in 2.0.0.6 and then found it didn't apply to 3.0a1pre, so I guess this is moot, but I'm posting my findings here in case they're useful. Here is the code that triggers the behavior in TB 2.0.0.6: // begin var emailAddr = "me@example.com"; var rdfService = Components.classes["@mozilla.org/rdf/rdf-service;1"] .getService(Components.interfaces.nsIRDFService); var parentDir = rdfService.GetResource("moz-abdirectory://") .QueryInterface(Components.interfaces.nsIAbDirectory); var enumerator = parentDir.childNodes; var addrbook = enumerator.getNext(); addrbook.QueryInterface(Components.interfaces.nsIAbDirectory); var searchUri = addrbook.directoryProperties.URI + "?(or(PrimaryEmail,c," + emailAddr + "))"; var directory = rdfService.GetResource(searchUri) .QueryInterface(Components.interfaces.nsIAbDirectory); directory.directoryProperties; // end It's the last line of the code that causes the extra prefs to be generated, even though it "does nothing" (except call an accessor method, presumably). There are a number of variations on the code that do not trigger the behavior. I couldn't find the directoryProperties member in nsIAbDirectory.idl, if that's where to look for it. Extra notes: 1) I was able to narrow down the source of the error by adding an observer to the "ldap_2.servers" prefs branch (nsIPrefBranch2) and watching when it triggered. However, the behavior occurred even without the observer. 2) I used a clean profile, except that I installed Venkman to run the code.

(In reply to comment #88) TB 3.x is unlikely to have this bug as we've dropped the directoryProperties and redone a lot of how the code fits together. > var searchUri = addrbook.directoryProperties.URI + > "?(or(PrimaryEmail,c," + emailAddr + "))"; Can you dump the searchUri to the console or somewhere and copy them back here. I suspect this may be the root cause of the problem in 2.x as I suspect the URIs may be invalid (it would also be useful to know at the same time the ldap_2.servers.xxx.filename prefs with their values).

searchUri = "moz-abmdbdirectory://abook.mab?(or(PrimaryEmail,c,me@example.com))" (TB 2.0.0.6, clean profile + Venkman) Created these prefs: user_pref("ldap_2.servers._nonascii.filename", "_nonascii.mab"); user_pref("ldap_2.servers._nonascii.replication.lastChangeNumber", 0); user_pref("ldap_2.servers._nonascii.uri", "moz-abldapdirectory://_nonascii.mab"); Re-executing the last line of the code snippet (i.e., calling the directory.directoryProperties accessor again) gives an additional triple, with _nonascii replaced everywhere with _nonascii_1. Each additional re-execution gives another triple, with _nonascii_1 incremented to _nonascii_2, etc., just like the other reports. No .mab files are created in the profile directory (which might be a clue for how to do the removal described in bug 357008). The change to TB3 explains why I couldn't find directoryProperties in nsIAbDirectory.idl. :-) I see now the address book/directory code has undergone some major revisions. Looks like the Change From+FCC extension, at least, is going to need a rewrite.