Open Bug 528503 Opened 10 years ago Updated 10 months ago

Multiple comma-separated addresses entered on single address line do no longer auto-complete after Enter was hit

Categories

(MailNews Core :: Composition, defect)

defect
Not set

Tracking

(Not tracked)

People

(Reporter: rsx11m.pub, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

I've noticed a major difference in behavior between TB 2.0 and 3.0 versions:

 - On current 2.0 releases, you can enter multiple addresses "ab,cd,ef" into
   a single line; they will turn red and don't autocomplete right away, but
   when hitting Enter they *do* autocomplete with each entry on a single line.

 - With 3.0 builds, entering "ab,cd,ef" won't autocomplete them either and
   turns the line to red, when hitting Enter they expand onto one line each
   *but* will stay red and do *not* autocomplete.

This may be related to bug 392932 but appears to be a regression on its own.

Also seen with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6pre) Gecko/20091111 SeaMonkey/2.0.1pre.
xref bug 497722.
Duplicate of this bug: 567672
Flags: wanted-thunderbird+
Duplicate of this bug: 664800
(In reply to rsx11m from comment #0)
> I've noticed a major difference in behavior between TB 2.0 and 3.0 versions:
> 
>  - On current 2.0 releases, you can enter multiple addresses "ab,cd,ef" into
>    a single line; they will turn red and don't autocomplete right away, but
>    when hitting Enter they *do* autocomplete with each entry on a single
> line.
> 

rsx11m, can you elaborate on this with an example (including STR, actual result, expected result)?
This would only work for comma-separated list of fully typed (or at least unique substrings of) email addresses, right? Or is it about resolving comma-separated list of nicknames, as in Bug 325458 Comment 21?
No, it's not just about nicknames. If I remember correctly, in Thunderbird 2.0 and earlier you could enter partial addresses in a comma-separated list and they would autocomplete like single addresses do now. That broke with 3.0.

More details with STR are in bug 567672 (duplicate of this one).
See Also: → 392932
Potential candidate per bug 392932 comment #16: bug 370306 attachment 325961 [details] [diff] [review], checked in on 2008-06-20 for 3.0b2.
Duplicate of this bug: 456550
I think the add-on MRC Compose (https://addons.mozilla.org/en-US/thunderbird/addon/mrc-compose/) solves this bug.
Attached patch Possible patchSplinter Review
Attachment #8976970 - Flags: review?(gds)
Attachment #8976970 - Flags: feedback?(frgrahl)
Comment on attachment 8976970 [details] [diff] [review]
Possible patch

I think gds is no longer active.
Sorry was a bit swamped but will see that I check this one out soon.

Neil, against which tree was this one done. It doesn't look like comm-central?
Flags: needinfo?(neil)
Attachment #8976970 - Flags: review?(gds) → review?(mkmelin+mozilla)
I'm still here. Been meaning to try/test the patch but I probably don't have the knowledge of the code in this area to actually do a good review.
Comment on attachment 8976970 [details] [diff] [review]
Possible patch

Review of attachment 8976970 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/components/compose/content/addressingWidgetOverlay.js
@@ +1085,5 @@
>    },
>  
>    autoCompleteNextAddress:function()
>    {
> +    this.numSessionsToSearch = 2;

why is this always 2 now? even if ldap isn't being used.
Sorry Gene if I jumped the gun.

The patch doesn't appy clean to me in c-c.
Comment on attachment 8976970 [details] [diff] [review]
Possible patch

Some formalities:

+  abSearch: Components.classes["@mozilla.org/autocomplete/search;1?name=addrbook"].getService(Components.interfaces.nsIAutoCompleteSearch),
+  ldapSearch: Components.classes["@mozilla.org/autocomplete/search;1?name=ldap"].getService(Components.interfaces.nsIAutoCompleteSearch),

It is Cc and Ci now only after the latest round of changes in Gecko made them global constants. The c-c source was mass changed for this.

>   QueryInterface : function(iid)
>   {
>-      if (iid.equals(Ci.nsIAutoCompleteListener) ||
>      if (iid.equals(Ci.nsIAutoCompleteObserver) ||
>           iid.equals(Ci.nsISupports))

This should be
>  QueryInterface: ChromeUtils.generateQI(["nsIAutoCompleteObserver"]),

SeaMonkey has not ported this yet. We are broken since 2.56 and fixing up 2.57 first.

> +++ b/suite/mailnews/compose/addressingWidgetOverlay.js
...
> -    }
> +    this.processAllResults();

You missed a closing bracket either before or after here.

And same question as Magnus. Can an ldap search be made without ldap?

Clearing feedback for now until a new patch arrives. I will backport it to 2.53 to test it then.
Attachment #8976970 - Flags: feedback?(frgrahl)
Comment on attachment 8976970 [details] [diff] [review]
Possible patch

Review of attachment 8976970 [details] [diff] [review]:
-----------------------------------------------------------------

Clearing r? awaiting comments
Attachment #8976970 - Flags: review?(mkmelin+mozilla)
Attached patch 528503-gds.diffSplinter Review
Applied the patch manually (patch -p1 < 528503.diff) resulting in one conflict/reject (as pointed out above). I changed 

QueryInterface: ChromeUtils.generateQI(["nsIAutoCompleteListener"]),

to

QueryInterface: ChromeUtils.generateQI(["nsIAutoCompleteObserver"]),

and re-built.

It work when I put in To: string like this:

av,gdsm,gene,k9

it expanded to 4 separate To: lines on hitting enter. Without the patch, it didn't expand.

I can't really comment on the code validity other than it seems to work. Also, I don't run suite/seamonkey so can't test both files. However, the suite file patched OK with no conflicts.

Attached is a conflict-free patch based on the fix above.
Clearing old NIs
Flags: needinfo?(neil)
You need to log in before you can comment on or make changes to this bug.