348825 - Invalid/non-FQ mail address in a pasted list soft-fails

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Jeroen van der Ham]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060613 Camino/1.0.2
Build Identifier: Thunderbird version 3 alpha 1 (20060815)

Whenever you paste a list of mail addresses directly into a compose window, and one of the mail addresses is in an invalid form, then that address and the rest following it is silently ignored.

Reproducible: Always

Steps to Reproduce:
1. Copy a list of mail addresses, for example the following one:

[e-mail]
eveexample.com
[e-mail]

2. Paste this list into the To: field of the compose window

3. The list is (correctly) translated into the form: [e-mail],eveexample.com,[e-mail]

4. Move to the next field or the body area

Actual Results:  
The list is parsed and only "[e-mail]" is included as recipient.
The rest of the list is silently ignored.

Expected Results:  
Thunderbird should *at least* present an error message stating that it found an invalid address and ignored the rest of the list.

Even better would be to make a best effort and parse the valid mail addresses and only present errors about the ones that are not valid.

Comment 1

[Wayne Mery (:wsmwk)]

*** This bug has been marked as a duplicate of 272165 ***

Comment 2

[Mike Cowperthwaite]

Reopening; I don't think this is a dupe.  I can reproduce the basic symptom of the other bug; I'll add a comment there.

I can't reproduce this one.  My results at step 4, using 2a1-0927 and 
3a1-0915, are that the three separate addresses placed in three separate fields, as expected; this is with Windows 2000, possibly the behavior is different on the Mac.  It's also possible there's an extension in reporter's installation which is causing this -- Jeroen van der Ham, if you have extensions installed, please try restarting in Safe Mode and see if the symptom persists.

With the example provided, with "autoCompleteMyDomain" turned on, the 2nd address is turned into, for example,
  [e-mail]

Comment 3

[Wayne Mery (:wsmwk)]

True, but "The rest of the list is silently ignored" is what happen's if autoCompleteMyDomain is turned off.  STM this matches with bug 272165.

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> True, but "The rest of the list is silently ignored" is what happen's if
> autoCompleteMyDomain is turned off.  STM this matches with bug 272165.

Ah-ha!  You are correct, that setting is important.  Still, there's a difference:  If I click a mailto such as:
  mailto:eveexample.com
the compose window fills in the address field; in the other bug, it's left blank due to not being parseable.  So, there's a different behavior handling the mailto (that bug) and a pasted list (this bug).

Seamonkey doesn't have this problem because it doesn't change <newline> to <comma> on paste.  That's a pretty nifty little feature in TB that I'd never noticed before, dating back to 1.0; however, 1.0 doesn't show this bug because 1.0 *always* performed autocomplete-to-domain.

And pasting a single, bad address doesn't cause it to disappear, even if it's badly broken like the example at that other bug.

Comment 5

[Mike Cowperthwaite]

(In reply to comment #4)
> Seamonkey doesn't have this problem because it doesn't change <newline> to
> <comma> on paste.

Bug 85655.

Comment 6

[Sorin Adrian Savu]

This reproduces only if you move to the next row using the TAB key or Return Key which do autocomplete (arrow keys leave the field alone) .
The messenger tries to auto complete all the recipients in that line, goes trough all the auto complete results, searching for a result with a valid index, if it doesn't find any, goes trough all the search results that have an invalid default index, and tries to use the result with index 0, without checking if there is an actual result and it fails with:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsISupportsArray.QueryElementAt]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://messenger/content/messengercompose/addressingWidgetOverlay.js :: anonymous :: line 1187"  data: no]

when mail.identity.default.autocompleteToMyDomain is set to false (or the identity used for that mail). This is because the second search is probably used for searching for autocompleted addresses. 

Doesn't seem to be related to copy pasting

The best approach seems to be to check if the search result with the defaultindex set -1 has any results at all.  Another approach would be not to return such results (the ones with defaultindex set to -1 if they are empty)


I will be creating a patch  to check for the number of elements in the result, actualy I have created the patch, but it seems to break when trying the testcase twice, so I need to investigate that further (seems to be related to Ldap, if I disable that it works fine)

In before I finish investigating, I hope the information above helps to clarify duplicate bugs, and mark them apropriately.