Closed Bug 497722 Opened 16 years ago Closed 15 years ago

Address auto-complete gives random order, not based on frequency after upgrading from Thunderbird 2 to Thunderbird 3 (autocomplete)

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(thunderbird3.1 beta1-fixed, blocking-thunderbird3.0 .2+, thunderbird3.0 .2-fixed)

RESOLVED FIXED
Thunderbird 3.1b1
Tracking Status
thunderbird3.1 --- beta1-fixed
blocking-thunderbird3.0 --- .2+
thunderbird3.0 --- .2-fixed

People

(Reporter: bernie, Assigned: standard8)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

(Keywords: fixed-seamonkey2.0.3, regression, Whiteboard: [DO NOT comment, see comment 77 and file a NEW bug if necessary])

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 Using a TB v2 profile with 3.0b2, when entering a TO: e-mail address, Thunderbird is not auto-completing/suggesting the most frequently used address. Worse, it messed things up so that using the profile in TB 2.0.0.21 is no longer suggesting the most frequently used addresses. Using a new profile in 3.0b2 appears to be working correctly, although I only have a small address book so far in 3.0b2 and less chance of making an incorrect auto-complete suggestion. Reproducible: Always
Do you use LDAP in your autocomplete? What doesn't work: no email addresses shown, or just some?
I use only the Thunderbird address book. Normally, in TB v2 if I start to type "den" in the To: field of a note, it auto-completes "denise" and lists alternatives that begin with den. However, using the same profile in 3.0b2, it auto-completes with "dennis" and lists the alternatives, with denise being far down the list. Worse, using that profile in v2.0.0.21 again, v2 now also auto-completes with "dennis". It seems to have lost whatever information it knew about the preferred addresses. V2 seems to be slowly relearning the correct preferences. Using a new profile in 3.0b2 I don't have many addresses in the address book of the new profile so I can't comment on how well it is working with the new profile.
Tony, do you also see this in SM? (summary needs improvement)
Let me add that likely related to this is that when auto-complete *does* work (it does for me in 3-beta2), it only shows the primary email address and never the "Additional email" address. That is, I do not get a chance to selct from among the two addresses for the person whose, say, name I began to type. Again, auto-completion does present the primary address (ie, auto-competion is correctly matching the email entry), but it only presents the primary email address as a completion-option. this used to work fine in 2.x. I am running Linux FC11 on a Dell Precision 390.
Likely that this is the same behavior as Bug 488235.
I also confirm for TB3.0b3 (Mac OS X) that autocomplete is not picking the most frequently used address. If it helps any, I'm using the same profile, switching back and forth between TB2 and TB3, including address books.
I am also experiencing this behavior with TB3.0b4 (Win Vista). The bug seems to be most prevalent when typing slowly, letter by letter, waiting for the auto complete list to populate. In addition, backspacing seems to exacerbate the frequency of auto complete selecting an unintended and less frequently used email address. I should also note that this behavior was only recently introduced and was not a problem when using TB 2.0. I am not certain as to which update introduced the bug, as it does seem tied to typing speed.
I confirm I also have this problem in TB 3.0.0 on Windows [details: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl-PL; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.0]. Also bug 532639 seems related to this one to me.
(In reply to comment #9) > Also bug 532639 seems related to this one to me. Indeed but different.
a lot if complaints about this on hendrix and elsewhere. we should want this for 3.0.1 IMO, bug 532639 is filed because of this bug, and would not be needed once this is fixed. in fact, I think there is a wontfix or invalid bug filed on that exact issue.
blocking-thunderbird3.0: --- → ?
Summary: Address auto-complete not working properly after migrating to 3.0b2 → Address auto-complete not working properly, not ordering based on frequency after migrating to 3.0b2
I also see this problem with Thunderbird 3.0rc2: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091130 Thunderbird/3.0 The order in which Thunderbird 3.0rc2 prefers address auto-complete entries seems to be random (not even alphabetical), and it sometimes does not show all of the auto-complete entries. Thunderbird 2.0 never had this problem (I did not try downgrading to Thunderbird 2.0 to see if it would inherit the problem from Thunderbird 3.0rc2). In addition, if you type comma-separated partial addresses, it will not auto-complete them when you press Tab or Return. Thunderbird 2.0 did this correctly. (Note: Before reporting this, I tried to update to 3.0 final release as the auto-update mechanism offered, but got an error that the file could not be found, so I'll have to try this after I get back at the end of the month.)
Assignee: nobody → bugzilla
blocking-thunderbird3.0: ? → needed
Ok, now I've hit this and I can see what is happening, I want to get this fixed for 3.0.1. This issue will affect anyone upgrading from 2.x who has sent an email more than 9 times to any one address book contact. As you'd expect the address book popularity field is handled as a integer. However as Mork is a text based database, it actually saves the integer on disk as hexadecimal. This worked fine in Thunderbird 2. Due to the Thunderbird 3 changes to deal with fields more generally, the popularity field is now read as a string in the address book database code. When it gets back to javascript, it is something like "e" or "1a" depending on its actual value. The conversion to a number in javascript results in NaN which then gives incorrect/random results in the popularity check coupled with the results not also being returned in the same order gives a rather random result. I can easily "fix" the randomness, but it doesn't fix the storage of the popularity field which needs a bit more work.
blocking-thunderbird3.0: needed → .1+
Confirmed the above behavior in Thunderbird 3.0 final release on Windows XP SP3: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 In particular, one thing that is broken appears to be not random: if you type comma-separated partial addresses, it will not auto-complete them when you press Tab or Return -- this apparently NEVER works, although it does separate the addresses onto 2 "To:", "Cc:", or "Bcc:" lines (this first step seems to work consistently). As noted above, Thunderbird 2.0 did this correctly (that is, doing the auto-completion in the process of separating the addresses).
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 I recreated my profile from scratch and I after sending email to one particular "kevin" several times, he still shows up as third in the dropdown list. I did not send any emails to the other "kevins". The title of this bug report includes the qualifier "after migrating to 3.0b2". My experience suggests that this part of the title can be deleted. Anyone else?
Summary: Address auto-complete not working properly, not ordering based on frequency after migrating to 3.0b2 → Address auto-complete not working properly, not ordering based on frequency after migrating to 3.0b2 (autocomplete)
Version: Trunk → 3.0
blocking-thunderbird3.0: .1+ → needed
Whiteboard: [resolve gs report when marking bug fixed]
I see this too. Can we change the status to something more appropriate now please? Thanks.
(In reply to comment #23) > Can we change the status to something more appropriate now please? Thanks. I assume you mean the subject, because the status is correct. In any case it needed clarifying anyway.
Summary: Address auto-complete not working properly, not ordering based on frequency after migrating to 3.0b2 (autocomplete) → Address auto-complete gives random order, not based on frequency after upgrading from Thunderbird 2 to Thunderbird 3 (autocomplete)
Whiteboard: [resolve gs report when marking bug fixed] → [resolve gs report when marking bug fixed][gs]
Thanks for updating Subject. It needed doing. I was really asking about Status though, just to know what the status is. Is a fix for this issue likely to make the 3.0.1 release?
Flags: blocking-thunderbird3.1?
Flags: blocking-thunderbird3.1?
(In reply to comment #25) > Thanks for updating Subject. It needed doing. I didn't upgrade from TB2. I installed TB3 and created a new profile, but I see this behavior. I would strike "after upgrading from Thunderbird 2 to Thunderbird 3". The problem is bigger than that. Note: I have a corporate LDAP server that I use as well.
Flags: blocking-thunderbird3.1+
(In reply to comment #26) > (In reply to comment #25) > > Thanks for updating Subject. It needed doing. > > I didn't upgrade from TB2. I installed TB3 and created a new profile, but I > see this behavior. I would strike "after upgrading from Thunderbird 2 to > Thunderbird 3". The problem is bigger than that. I have tested TB 3 on several occasions, and there are automated tests that imply that TB 3 works correctly in the non-upgrade situation. > Note: I have a corporate LDAP server that I use as well. Did you try disabling that? If you didn't then I'd say that you're not necessarily testing the same circumstances as this bug and your issue could be a different one.
blocking-thunderbird3.0: needed → .2+
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2pre) Gecko/20100118 Lanikai/3.1a1pre I disabled LDAP searches and get similar results. There are several people with the string "kevin" in my local address book. They pop up in an order that does not take into account the number of emails I have sent to them. I sent the one at the bottom of the list two emails, and the order never changed. Is there a way to reset the counting, something short of re-creating my profile again? Also, I would propose that regardless of where the names/addresses come from (TB local address book, Mac OS X Address Book, or LDAP server), that the combined output be sorted by usage.
This is simply a *nightmare*. Mail address completion never, not once, works for me for any address (all my contacts have multiple addresses, don't yours, and I have hundreds of contacts with identical first few characters) in TB3. This mail program is simply unusable for me after this "upgrade". You have my vote, and the future bug-fixer/improvement-de-regresser willhave my gratitude. PS How I'd *like* this to work, personally: * The only address book I use is the MacOS address book. (Nice new feature in TB3), in theory. * When I type addresses, the completion list is sorted by frequency of past contact (highest weight to my "Sent" folders, lower weight for senders.) If I don't normally an alternate address for some contact, I don't want to be offered it except as a last-priority resort. * I don't want to be forced to maintain a Thunderbird-only address book just to make this happen.
Folks: Let's be clear, this bug is about fixing the randomness caused by upgrading from Thunderbird 2 to Thunderbird 3 and restoring the order as close as it can be to Thunderbird 2. Improvements in frequency, frequency coverage for non-local address books are all different bugs and the latter is certainly not going to be possible in 3.0.x due to the current architecture of how the address book works. We will be looking in the address book in more detail as we move forward into 3.1 and beyond, however, please do not turn this into a discussion bug with random ideas thrown in as they will only get lost once we fix the bug.
(In reply to comment #31) > Improvements in frequency, frequency coverage for non-local address books are > all different bugs and the latter is certainly not going to be possible in > 3.0.x due to the current architecture of how the address book works. Is there already a bug for the larger issue? If not, I'd be happy to create it.
This is an extremely annoying change in operation. I am used to being "sloppy" I guess because the T2 worked so much better than T3. How hard is it to migrate back to T2? It is a better program than this one.
(In reply to comment #33) > This is an extremely annoying change in operation. I am used to being "sloppy" > I guess because the T2 worked so much better than T3. Please be aware that this was not an intentional change, and as has already been said, we are working on fixing it.
(In reply to comment #31) > Folks: Let's be clear, this bug is about fixing the randomness caused by > upgrading from Thunderbird 2 to Thunderbird 3 and restoring the order as close > as it can be to Thunderbird 2. Mark, I know you're getting hit from all sides here and I totally understand your frustration. Been there Users need to understand that this is NOT A SUPPORT FORUM, a gentle reminder now and then will help reinforce that. I am hoping there is one thing you can review in an objective fashion: A few users, including myself, are experiencing this bug WITHOUT any upgrade from TB2. In fact, I made 100% sure that there was no Thunderbird config directory prior to TB3 installation. In my case, I'm using MacOS 10.6 and the Mac OS X Address Book. Could that also have some effect on the randomness issue? Your work on this issue is very much appreciated.
(In reply to comment #15) > In addition, if you type comma-separated partial addresses, it will not > auto-complete them when you press Tab or Return. Thunderbird 2.0 did this > correctly. This was previously filed as bug 528503.
I appreciate Mark's work on this but also find this very frustrating! I did upgrade and do experience this randomness using the TB address book. In my case it also never resolves an alias, but once typed, the alias now appears as an option on the dropdown-list, but of course does not resolve into a valid address. I understand this might be yet another bug, but it also might help find a solution.
Sorry to pile on, but I was expecting completion to sort the main address from my address book before the additional address. But it seems like I'm getting alphabetical completion within the addresses for a single person. This is very bad for me --- I carefully chose which would be the primary address for many of my contacts. Main case: my coworkers have both company email addresses and gmail addresses. Our company name starts with "s" so I have started to get Thunderbird pushing gmail addresses on me, and those are really not appropriate.
I reopened and clarified Bug 535805 to track the larger effort. Let's take technical discussion of that topic there. Per Mark's comments, this bug report is focused on the TB2 -> TB3 upgrade issue.
+1 vote All work on this bug is appreciated!
+1 Vote
Attached patch The fixSplinter Review
Fix with unit tests. The address book file had the popularity index generated and saved by TB 2. The code now handles the hex values properly and turns them into integers as David and I discussed offline. The code and tests cover both cases where we get the popularity index (autocomplete and sending) although I suspect that realistically the autocomplete case is the one that will be hit most of the time (but just in case, both are fixed anyway). The vast majority of this patch is the unit test additions.
Attachment #424979 - Flags: superreview?(bienvenu)
Attachment #424979 - Flags: review?(bienvenu)
Attachment #424979 - Flags: superreview?(bienvenu)
Attachment #424979 - Flags: superreview+
Attachment #424979 - Flags: review?(bienvenu)
Attachment #424979 - Flags: review+
Comment on attachment 424979 [details] [diff] [review] The fix If it weren't for exisitngt 3.0 users, I would have suggested changing the get/set int property code to store integers in hex in mork...
(In reply to comment #46) > (From update of attachment 424979 [details] [diff] [review]) > If it weren't for exisitngt 3.0 users, I would have suggested changing the > get/set int property code to store integers in hex in mork... I did consider that, but the problem is that we'd then need knowledge about integer versus text fields which the new AB code doesn't really support. Guessing could lead to mistakes of loosing whitespace e.g. in the telephone fields.
(In reply to comment #45) With this patch, TB 2 values > 10 will not get fixed unless they contain a digit from [a-f] that identifies them as hex (e.g. TB 2 "20" will not change to TB 3 "32", as it should). Alas, such an effect seems to be unavoidable unless the code keeps track of the base for each number (or converts all numbers in one go during upgrade).
(In reply to comment #48) > (In reply to comment #45) > > With this patch, TB 2 values > 10 will not get fixed unless they contain a > digit from [a-f] that identifies them as hex (e.g. TB 2 "20" will not change to > TB 3 "32", as it should). Alas, such an effect seems to be unavoidable unless > the code keeps track of the base for each number (or converts all numbers in > one go during upgrade). Yeah, I've considered various options but part of the problem was that as we didn't pick up on the issue earlier we've got TB 2 users with hex values and TB 3 users with decimal, and we've got no way of telling which is which. This fix will probably affect the order in some cases compared to the order originally shown in TB 2 but we can't do much about that, and the order will at least be stable again. Additionally as users continue sending email, the order according to popularity should restore themselves out again. The other good news is that we now have a few more automated tests for this, which should help stop issues occurring again in the future.
This is now checked into our Lanikai 3.1 nightlies and trunk 3.2 nightlies. It is not yet fixed in the 3.0.x nightlies. http://hg.mozilla.org/comm-central/rev/eff6ccd2f12b Once it has baked on trunk/3.1 for a couple of days we'll get it into 3.0.x in time for 3.0.2. The bug is being marked as fixed as it is fixed on trunk. The status-thunderbird3.0 flag shows its status on 3.0.x and will be updated when it gets checked in to 3.0.x.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1b1
Flags: in-testsuite+
Attachment #424979 - Flags: approval-thunderbird3.0.2?
Comment on attachment 424979 [details] [diff] [review] The fix SM are doing a release off of c-1.9.1 before we're ready for 3.0.2. Although I'd normally let this bake a bit longer on trunk builds, it has tests and getting some extra exposure won't hurt. Therefore a=me for my own patch, low-medium risk but high value.
Attachment #424979 - Flags: approval-thunderbird3.0.2? → approval-thunderbird3.0.2+
This bug is still present in 3.0.1
That's because this was checked in after 3.0.1 was released.
I have migrated my mail and address book from TB 2.0.0.23 to TB 3.0.0 on Windows [details: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl-PL; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.0]. and encountered this problem (https://bugzilla.mozilla.org/show_bug.cgi?id=532639#c4). Later I upgraded to TB 3.0.1 and just today I upgraded to 3.0.2 beta [Mozilla/5.0 (Windows; U; Windows NT 6.1; pl-PL; rv:1.9.1.8) Gecko/20100216 Lightning/1.0b1 Thunderbird/3.0.2] (I used this build: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/3.0.2-candidates/build1/win32/pl/Thunderbird%20Setup%203.0.2.exe) and this issue is apparently still present. Is this because of what is stated in comment #48? Is there really no option to tell if the TB 3.x profile originates from TB 2.x? :(
Grzegorz, please can you clarify your steps to repeat this problem. For example, if you follow the following steps, is the order random or constant: 1) Open compose window 2) Enter one or two characters that will match more than one email address. 3) Observe the results. 4) Delete those characters 5) Without doing anything else, re-enter the *same* characters 6) Observe the results. are the results different at step 6 than they were at step 3, or are they always consistent?
And again, note that you need to use Thunderbird 3.0.2 (currently available as candidate builds, ot yet as actual release) as that is the _first_ release of 3.0.x to have this bug corrected.
(In reply to comment #57) > Grzegorz, please can you clarify your steps to repeat this problem. For > example, if you follow the following steps, is the order random or constant: > > (...) The order is constant here. What does it mean?
(In reply to comment #59) > (In reply to comment #57) > > Grzegorz, please can you clarify your steps to repeat this problem. For > > example, if you follow the following steps, is the order random or constant: > > > > (...) > > The order is constant here. > > What does it mean? If the order is constant on 3.0.2 then it means that whatever issue you mentioned in comment 56 isn't the same as this issue. This bug was specifically about stabilising the order so that whenever you type the same characters, you get the same result. What we therefore need is a better description of what makes you think that "this issue is apparently still present".
Sort order has not changed for me from 3.0.1 to 3.0.2-candidate. Mac OS X 10.6, using TB 3.0.2 build from 3.0.2-candidates/build1. Profile NOT upgraded from TB2. My sort order appears to be based on a simple alphabetical sort of the entire string (First Last <email>). We might have two or more separate issues here.
> Sort order has not changed for me from 3.0.1 to 3.0.2-candidate. Confirmed. > > > My sort order appears to be based on a simple alphabetical sort of the entire > string (First Last <email>). > > We might have two or more separate issues here. Exact same issue here using 3.0.2 candidate builds (from auto-update) on Linux. This is certainly a separate issue.
Please clarify what is the solution that was implemented. I have upgraded from V2 through each update to V3.0.1. Comment 31 says that this is about fixing randomness. I have seen no randomness. I have seen a different ordering to what was used in V2. The only two solutions that are acceptable are: - restore the order as it was in V2 - allow a user to clear any saved ordering so that we can start again Currently a less used email address is always at the top and there appears no way to reset this.
Protz tells me his issue is actually Bug 543088: "Autocomplete - primary email address no longer appears before additional email address (now sorted alphabetically)". For users who are using 3.0.2 (candidate or release) and believe they are still seeing an issue with auto complete, please check out: https://wiki.mozilla.org/User:Standard8/Thunderbird_Autocomplete This documents the current algorithm that we use and the known issues. If your issue is not one of the ones listed, or you think it is behaving differently, please file a new bug with full steps to reproduce and a clear description of what you are seeing in your results.
A few things: 1. Perhaps somebody is (willfully? accidentally?) misinterpreting the possible programmer-colloquial mis-use of the term "random". The bug report may not be that the order varies every time it is presented, in a random or quasi-random fashion, but that FROM A USER PERSPECTIVE, the order presented is not correlated with the user's desired sorting order. 2. Presenting a primary address from one mailbox first when auto-completing an address, is only one part of the desired behaviour. In fact, *always* presenting this address first would be a bug from my perspective. 3. Here's what I, AS A USER, want to see and expect to see and, for the most part used to see in TB 2, and which I don't see in TB 3, which makes this "upgrade" a constant source of frustration and loathing for me: (A) When auto-completing addresses, the MOST-USED matching completion should be sorted to the top of the list, and less-used completions should appear lower. This is INDEPENDENT of whether the email address is designated as "primary" for a particular address book entry. (B) The "most-used" order should be weighted most strongly by addresses to which I have sent mail. If we have to start form scratch and you can't recover that information from TB2 or buggy TB3 data, fine. Just start doing the right thing AS SOON AS POSSIBLE. (..B2) In an ideal world, addresses I type in manually or select manually from an auto-completion list would be weighted more strongly than addresses which are filled in automatically by "reply" or "reply to", but this is a small enhancement request compared to fixing the horribly broken main bug. (C) When multiple completions with the same most-used count match a partial input string, give preference to addresses that are designated as "primary" address book entries. Note that this is a SECONDARY SORT ORDER -- the most-used criterion should always win out over a primary designation. (..C2) enhancement request, but just since I'm listing how I want things to work: addresses designated as "other" (versus "work", "home", etc) in my MacOS address book should have lowest priority. This is like being designated the opposite of primary. Again, it only affects a secondary sort order. (My address book has many alternate and or former email addresses which I keep for various database and historical reasons. No, I am not going to manually delete them; so it would be nice if stuff that used by address book, like Thunderbird, were smart enough to value some email addresses more than others.) (D) I only want to use one address book on the platform I use, namely the MacOS address book. Any "fix" to this bug or class of bugs that requires me to copy information into some Thunderbird-specific address book, or to maintain multiple parallel address books, IS NOT A FIX. (I don't care where Thunderbird stores its most-frequently-used address count; that doesn't have to be in my one system-wide address book since it's likely to be application-specific data. What I don't want is any *user-visible* evidence of this, in particular in the form of a user-visible Thunderbird-specific address book.) Sure, in the technical nit-picky sense this bug might be "resolved" even if it involves a work-around, but form the point of view of releasing a software product that USERS WILL WANT TO USE and that will not IMMEDIATELY GENERATE COMPLAINTS AND BUG REPORTS I think it is important to deal with this issue (D) at the same time. If that's a separate bug, fine, but in my opinion it's a separate bug that ought be a release-blocking must-fix. Yes, this is just one platform and I'm just one user, but my expectation here ia a very obvious one, and I found in a casual survey (3 datapoints!) of other users than that (all MacOS plaform) expect the same thing. Thanks. I'm really trying to be helpful here, and I don't think my expectation as a USER are unrealistic or extremely idiosyncratic. Getting email addressing to work right (ie more of less "invisibly", ie so correlated to reasonable user expectations that the user never needs to think about it) is one of the most important parts of the mail reader UI in my opinion. Look at the work that has gone into making the Firefox address bar as useful and convenient and as "do the right thing nearly every time" as it is today -- that's a big selling point for Firefox adoption, and the equivalent will make TB more attractive to new users (and frustrated existing users after the TB3.0 downgrade-upgrade.)
I 100% agree with Richard (although I am using WinXP) so you have 4/4 in your poll! While 'technically' this bug has been fixed, the behavior of TB3 is annoying to the point where I guess everybody wishes they never downgraded to TB3! It appears to me that Mark would want us to pile on bug 535805 which currently is not blocking, but should be! So lets take it there and vote it blocking!
I agree with Richard. I've already inadvertently sent confidential information to the wrong recipients and would not care to repeat that mistake. The TB2 behavior is best.
My point (D) above is Bug 543114. My implementation guess is that fixing the other issues might also fix Bug 543114 "for free", since my guess or naive suggestion about the correct implementation solution for this whole class of bugs is to store mosted-used email address completions as strings in a separate, very simple database, that simply maps string->count, and to do this independent of any particular user-visible address book. Another nice side effect is that this should end up being completely platform-independent. Hooray! And again, I'm really trying to be helpful here ... short of doing any programming.
I have just submitted Bug 547671 which describes a problem that is not "random" and is not covered on https://wiki.mozilla.org/User:Standard8/Thunderbird_Autocomplete .
Don't want to repeat anything, but having just moved to 3.0, I want to ditto this bug... In 2.0 I never had a problem, if I pressed "S", it would bring up the "Spam Control" entry from my address book. I assume it knew that I e-mailed to that addy the most often. 3.0.3 doesn't do that now, it brings up my sister who I don't e-mail as often & then my bookkeeper who's name is Erin (no "S" there). Then finally the 3rd one down on the list is Spam Control. Thanks Michelle
To make it 5 out 5, I also agree with Richard. Please bring back the functionality we all admired in version TB2. Despite the bug status of 'RESOLVED FIXED' the functionality is not 'fixed' in the common meaning of those of us who are non-technical users. Thanks. Mark
I have not yet tested 3.0.3 If current functionality works as described in https://wiki.mozilla.org/User:Standard8/Thunderbird_Autocomplete, then I consider that 100% satisfactory. If it doesn't work that way, I'll file a new bug.
This is not a full test, but as far as I can tell, this looks fine for me. Previously all my colleagues' @gmail.com addresses (rarely, if ever, used) came out, lexicographically above their @sift.info addresses (very commonly used). This behavior no longer occurs in my copy of 3.0.4.
It's still not working for me either even with the new upgrade of 3.0.4 It doesn't bring the most commonly used addys to the top if there are many other addys that start w/ that same letter. Michelle
Same here at 3.04 Mark
Please DO NOT comment on closed bugs. Your comments will most likely be lost and your issue not fixed. We are NOT reopening this bug as it did indeed fix an issue for lots of users. We have a general standard of one issue per a bug, otherwise separate issues get lots. If you believe you still have an issue with the auto-complete algorthim: 1) Read https://wiki.mozilla.org/User:Standard8/Thunderbird_Autocomplete This details the current state of the algorithm, known issues at 3.0.4 and previously fixed issues. 2) If you still have an issue, file a NEW bug, including full details of what isn't matching your expectations and examples of how the order is varying from your expectations. Thank you in advance for following these rules. Doing so will ensure that we can track down any remaining issues and improve Thunderbird.
Whiteboard: [resolve gs report when marking bug fixed][gs] → [DO NOT comment, see comment 77 and file a NEW bug if necessary]
I tested 3.0.4 and the issue appears fixed to me. Note that it can take a while to build new history with your addresses for it to start picking the right ones.
What's a while? Oh you mean b/c 3.0.4 is still new? It's still not finding that one address, but I'll give it another couple of weeks & if it's still doing it, report back. Thank you Michelle
Hi there, Ok, it's still not working, my sister's e-mail address is still coming up first. So how do I reopen this bug? Thanks Michelle
Michelle, You don't, you open a new bug with specifically the issue you're seeing. Please include a description of the various addresses involved and why you think that your sister's address first is incorrect. The bug originally described in this ticket is fixed; your issue is that the there is a glitch in the fix, for you. Alternately, you take your issue to #thunderbird on irc.mozilla.com and see if you can work it out there interactively first.
Hi, I don't use IRC & since I finally know my way around bugzilla, I decided to open a new bug on this. Thanks Josh : ) Michelle
Michelle, Somebody made a Wiki page that says the bug doesn't exist. Therefore the bug doesn't exist. And this is why free software is doomed.
(In reply to comment #83) Richard, with all respect for the personal frustration that unresolved issues may cause (believe me I know it), please refrain from adding negative, indiscriminate and non-cooperative commments. > Somebody made a Wiki page that says the bug doesn't exist. > Therefore the bug doesn't exist. Pls read comment 77 and the Wiki page again and find that both are very specific about what they *believe* [sic] to have fixed, outstanding issues, and migration issues that may not be fixable and/or will resolve themselves over time. (Quote from https://wiki.mozilla.org/User:Standard8/Thunderbird_Autocomplete) > As of Thunderbird 3.0.4 we believe the autocomplete algorthim now matches > Thunderbird 2 /as closely as possible/. > Known bugs in 3.0.4: [...] That's clearly NOT saying "it's all fixed and working exactly as before". (ctd. in reply to comment #83) > And this is why free software is doomed. Open Source Community Software enables and encourages YOU to look at the code and bring in your expertise and help improve the product, so that we will all benefit. Again, pls read comment 77 (by the same "somebody" who wrote the wiki), where such cooperation to fix potential outstanding issues is explicitly encouraged: (From comment #77) > 2) If you still have an issue, file a NEW bug, including full details of what > isn't matching your expectations and examples of how the order is varying from > your expectations. > Thank you in advance for following these rules. Doing so will ensure that we > can track down any remaining issues and improve Thunderbird. Please have a look at followup bug 565465 (by Michelle) and see if it describes your problem, or if you can help to improve the quality of that bug by adding more precise Steps to reproduce (STR). If your problem is different, please file a new bug with the necessary details. We'll appreciate your interest in the matter, and your cooperation.
To identify and resolve potential outstanding issues that may not yet have been fixed by this bug (see also: https://wiki.mozilla.org/User:Standard8/Thunderbird_Autocomplete), Michelle has posted this followup: bug 565465 - Thunderbird is not auto-completing/suggesting the most frequently used address
Depends on: 565465
Blocks: 546737
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: