From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) BuildID: 2000110409 Since the address book cards for Mozilla support an additional email address entry, this information should be displayed in the select address window accessed from the E-Mail Composer. These additional email addresses should also be displayed in the autocomplete textfield of the E-Mail recipient list. Otherwise, what's the point of entering this information if you can't get to it automagically ?? Reproducible: Always Steps to Reproduce: 1. Open E-Mail window 2. Select "New Msg" to open E-Mail Composer 3. Start typing recipient email address or select "Address" button Actual Results: Only the primary email address fields from the address book cards are displayed. Expected Results: Expecting Mozilla to display both the primary and additional/secondary email address (if available)
Assignee: putterman → ducarroz
OS: Linux → All
Hardware: PC → All
Summary: [FEATURE] Display additional email addresses in select address window → Also use "additional email addresses" for autocomplete
Status: NEW → ASSIGNED
Target Milestone: --- → Future
QA Contact: esther → pmock
*** Bug 67174 has been marked as a duplicate of this bug. ***
QA Contact: pmock → fenella
It would also be nice to be able to get at the additional e-mail addresses when selecting addresses from the "Select Addresses" dialog.
*** Bug 118092 has been marked as a duplicate of this bug. ***
*** Bug 83096 has been marked as a duplicate of this bug. ***
Nowadays, many people have multiple e-mail addresses; and it is not uncommon to want to send messages to *either* of the addresses. Therefore, I suggest to add the keyword: *mozilla0.9.9* (Becki Sanford?) OT: actually, we probably need more than just two e-mail addresses per person. I suggest 2 private, 2 business, and 1 "other". But that will be another bug...anyone?
> OT: actually, we probably need more than just two e-mail addresses per person. > I suggest 2 private, 2 business, and 1 "other". But that will be another > bug Bug 118665
*** Bug 147834 has been marked as a duplicate of this bug. ***
The target milestone has been marked "Future" since quite a long time. Any plan to move it to near Future, hopefully for Mozilla 1.0 :) ?
Pherhaps the Target Milestone should be changed to mozilla 1.2 final. The solution can't be this complicated, is it ? Anyone out there, working on this problem ? Tired of waiting J. Buesse
This patch add the support of the additional email address to emails autocompletion. I added a pref in addressing panel to turn off this feature
Comment on attachment 58381 [details] Possible e-mail address selection dialog This proposed UI for the select addressbook dialog doesn't not solve the problem when the user select several entries and press one of the buttons.
Attachment #58381 - Attachment is obsolete: true
comment #6 (select address dialoge) and comment #15 are irrelevant to this bug. This bug is (hopefully) only about the *autocomplete* when typing a name into the *compose* window. If we really must fix the "Select Address" window, I suggest to simply list the additional address on a second line. +----------------------------+ | PAB | mary email@example.com | | | mary firstname.lastname@example.org | <-- 2nd line ("Additinal e-mail") | | joe email@example.com | | | |
*autocomplete* when typing a name into the *compose* window is the major handicap, I see. And I believe it should be easy to implement. Hopefully already in Mozilla 1.2final. Just the posibility to select the right address from the autocomplete list, would make me happy. :-)
After review, we don't need to have a pref to turn on/off this feature. I'll post a new patch...
Whiteboard: have fix
same than previous fix but without adding a pref and a UI.
Attachment #103879 - Attachment is obsolete: true
Comment on attachment 104552 [details] [diff] [review] Proposed fix, v2 1) Nit: + case 0: rv = card->GetPrimaryEmail(getter_Copies(pEmailStr[i])); break; + case 1: rv = card->GetSecondEmail(getter_Copies(pEmailStr[i])); break; It’s easier to set breakpoint if ‘break;’ is a separate line. 2) + if (!(const PRUnichar*)pEmailStr[i] || ((const PRUnichar*)pEmailStr[i]) == 0) Looks like we just want to know if pEmailStr[i] is empty or not so consider: if (pEmailStr[i].IsEmpty()) . . . 3) + for (j = 0; ((const PRUnichar*)pEmailStr[i])[j] != 0 && + ((const PRUnichar*)pEmailStr[i])[j] != '@'; j ++) ; - if (((const PRUnichar*)pEmailStr)[i] == 0) + if (((const PRUnichar*)pEmailStr[i])[j] == 0) + pEmailStr[i].SetLength(0); + } Looks like we only want to know if pEmailStr[i] contains ‘@’, so consider: PRInt32 atSign = pEmailStr[i].FindChar('@'); if (atSign <= 0) . . . 4) + PRInt32 mNumberOfEmailAddresses; Do we need this since it’s not used in the patch?
I have addressed all Cavin's points except the first one which I consider not very usefull in that case.
Attachment #104552 - Attachment is obsolete: true
Comment on attachment 105194 [details] [diff] [review] Proposed fix, v3 r=cavin. You probably don't need declaration for 'j'.
Attachment #105194 - Flags: review+
correct, I'll remove j before check in
Comment on attachment 105194 [details] [diff] [review] Proposed fix, v3 sr=bienvenu
Attachment #105194 - Flags: superreview+
Fix checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.3alpha
Trunk build 2002-11-21: WinMe, Linux 8 , Mac 10.1.3 Verified Fixed.
Status: RESOLVED → VERIFIED
*** Bug 159944 has been marked as a duplicate of this bug. ***
From the "what it's worth" department... It appears that this bug was not completely fixed since bug #119413 was opened which addresses my original request. When typing in an address, the autocomplete should also attempt to pull addresses that were entered under the "Additional Email" field of the address book card. This feature is NOT present in Mozilla 1.4a (Linux).
I don't know whether to open a new "bug", so I first add it here: Autocompletion simply orders the two email addresses (email and additional email) and suggests the one that comes alphabetically first. In my opinion, it should always offer the address from the email field instead of the one from the additional email field, as the field names suggest. (BTW: the integration of the additional email field is great: recognizes both email addresses in the email rules when-in-address-book, pulls up both addresses in the auto-completion, etc. Well done!)
As you could see, bug 110049 depends on this one, and it seems to be more or less what you've described. I suggest that you write a comment to that bug to know if that corresponds your idea. If no, open a new bug (and perhaps also add an dependency) because this bug, as described by its name, is fixed. So it's not a good idea to "pollute" it.
You need to log in before you can comment on or make changes to this bug.