Closed Bug 492069 Opened 11 years ago Closed 9 years ago

Lightning corrupts ATTENDEE / ORGANIZER with CN parameter that contains a comma

Categories

(Calendar :: Dialogs, defect, major)

Lightning 1.0b2
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bernard.desruisseaux, Assigned: bv1578)

References

Details

(Whiteboard: [not needed beta][no l10n impact])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 X-ORACLE-DEBUG=STATS (.NET CLR 3.5.30729)
Build Identifier: Lightning 0.9

The Invite Attendee dialog automatically removes the double quotes from the common name of attendees that were already specified in the event. In the case of an attendee with a common name value that contains a comma, the CN parameter ends up being removed, and the attendee property value is set to the text that appeared in the common name before the comma, that is, the email address of the attendee is lost.

Reproducible: Always

Steps to Reproduce:
1- Create new event

2- Click on the "Invite Attendees" button

3- Add attendee the following attendee (with this exact text):

   "a,b" <a@example.com>

4- Click on the "Ok" button.

5- Click on the "Invite Attendees" button again

6- Notice that the attendee name is no longer specified within double quotes:

   a,b <a@example.com>

7- Click on the "Ok" button.

8- Click on the "Save and Close" button.
Actual Results:  
Mozilla Lightning generates the following ATTENDEE property:

  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:a

Expected Results:  
Mozilla Lightning should generate the following ATTENDEE property:

  ATTENDEE;RSVP=TRUE;CN="a,b";PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:
   mailto:a@example.com

This issue will occur more frequently to users that enabled the address autocompletion feature as Lightning will automatically add the user's common name found in a local address book or in LDAP.
Are you able to reproduce the issue using Thunderbird 3 Beta 2 (or newer) together with a recent Lightning 1.0pre test build?
Version: unspecified → Lightning 0.9
Seems to be fixed.  I got (anonymized)

ATTENDEE;RSVP=TRUE;CN="Second, First";PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:random@dev.null

With Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2
I  still have the problem (even with 1.0 pre) and lightning does corrupt
the invities address and hence could not send event mail.


Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090715 Lightning/1.0pre Thunderbird/3.0b3

Is there any work around for this .
Just to add more information..

I added multiple invites for my event..I am not sure where to see the
Attendee property to show how it is stored. Let me know, I will do that..

regards,
Balaji
Duplicate of this bug: 531198
Confirmed per duplicate bug. -> NEW
Status: UNCONFIRMED → NEW
Component: General → Dialogs
Ever confirmed: true
Flags: blocking-calendar1.0?
OS: Windows XP → All
QA Contact: general → dialogs
Hardware: x86 → All
Is this issue the same as bug 427949 (or vice versa)?
Yes It is same as 427949. 


regards,
Balaji
Duplicate of this bug: 427949
Duplicate of this bug: 559019
Summary: Lightning corrupts ATTENDEE with CN parameter that contains a comma → Lightning corrupts ATTENDEE / ORGANIZER with CN parameter that contains a comma
Flags: blocking-calendar1.0? → blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact]
Does this still happen with the latest 1.0b3pre nightlies?
I just tested this with Lightning/1.0b2, and the issue seems already be solved.
Thanks for testing!
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
The bug is still present with the same exact steps to reproduce reported in comment #0 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9pre) Gecko/20100808 Lightning/1.0b2pre Lanikai/3.1.3pre).

In the past I tried to look into this issue, what I found is that the parseHeadersWithArray [1] returns the |names| part without double quotes, i.e. with the attendee reported in bug description:

 "a,b" <a@example.com>
 
the parseHeadersWithArray's output is

emailAddresses = a@example.com
names          = a,b
fullNames      = "a,b" <a@example.com>

and the |names| part is exactly the value assigned to the attendee's commonName property [2]

Without changing the parseHeadersWithArray's behavior, I've tried to add some code that adds double quotes if the |names| string has comma, semicolon or colon, something like the following (just before line #566):

let str = names.value[0];
if (str.search(/[,;:]/) != -1) {
    str = "\"" + str + "\"";
    names.value[0] = str;                          
}

and this would fix the part related to the UI (no more problems described in comment #0 when saving, closing or opening the dialog) because now commonName is always "a,b". Although, it doesn't solves the bug because in the ics calendar, the double quotes are added again and it results a CN property with double quotes duplicated that corrupts again the attendee:

ATTENDEE;RSVP=TRUE;CN=""a,b"";PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:m
 ailto:a@example.com

These are my 2 cents.

Not sure whether this is the right approach, anyway I hope it could be useful.

[1]
http://mxr.mozilla.org/comm-central/source/calendar/base/content/dialogs/calendar-event-dialog-attendees.xml#544

[2] http://mxr.mozilla.org/comm-central/source/calendar/base/content/dialogs/calendar-event-dialog-attendees.xml#566
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
Version: Lightning 0.9 → Lightning 1.0b2
I confirm this long standing problem now on:

fedora-release-14-1.noarch
thunderbird-3.1.7-2.fc14.x86_64
thunderbird-lightning-1.0-0.35.b3pre.fc14.x86_64

There are lot of us in the company that this affects, since all names come back from the LDAP as in form of "surname, firstname" <firstname.middle.surname@company.com>.

I use the following calendar setup:
 lightning <-> DavMail CalDav proxy <-> Exchange server.
Hi,

I have noticed this bug on Thunderbird 3.1.7 on Gentoo. After some hacking I managed to fix the issue by introducing the following code into the "appendAttendee" method in calendar-event-dialog-attendees.xml XUL file (found in /usr/lib/thunderbird/extensions/\{e2fda1a4-762b-4020-b5ad-a41df1933103\}/chrome/calendar.jar on my machine). Patch against latest trunk:

diff -r 78440aa35ff6 calendar/base/content/dialogs/calendar-event-dialog-attendees.xml
--- a/calendar/base/content/dialogs/calendar-event-dialog-attendees.xml	Mon Nov 15 18:43:19 2010 -0500
+++ b/calendar/base/content/dialogs/calendar-event-dialog-attendees.xml	Mon Feb 07 17:59:06 2011 +0100
@@ -334,6 +334,7 @@
           var inputValue = aAttendee.commonName;
           var regexp = new RegExp("^mailto:(.*)", "i");
           if (inputValue && this.mHeaderParser) {
+	      inputValue = '"' + inputValue + '"'; // Make the commonName appear in quotes
               var email = aAttendee.id;
               if (email && email.length) {
                   if (regexp.test(email)) {



This fixes the issue when saving the ics and also sending an email to conference participants.
Thanks Maciej,

I verify this fixes it for f14 too. The patch has drifted a bit in lines, this is my manual patch with the same change:

--- content/calendar/calendar-event-dialog-attendees.xml.orig   2011-02-08 12:23:16.786034133 +0200
+++ content/calendar/calendar-event-dialog-attendees.xml        2011-02-08 12:47:39.463473538 +0200
@@ -338,6 +338,7 @@
           var regexp = new RegExp("^mailto:(.*)", "i");
           if (inputValue && this.mHeaderParser) {
               var email = aAttendee.id;
+              inputValue = '"' + inputValue + '"';
               if (email && email.length) {
                   if (regexp.test(email)) {
                       inputValue += ' <' + RegExp.$1 + '>';

Could someone please pick this patch to upstream? Decathlon's description is good one, and two of us already tested the patch to be working.
Seems working fine, maybe there's something to add in order to not make appear every name, even without comma, with double quotes in the attendees list.
I'm going to attach a patch.
The patch is based on code from comment #16.
I've only changed the way the double quotes are added to the common name i.e. only if the name contains a comma or semicolon, otherwise every name appeared with double quotes in the attendees list.
I've done the same in the list that appears in the Event dialog.

The patch resolves completely the problem described in bug description, but I'm not completely sure if something is missing. For example, when the user inputs a name 

    a,b <a@example.com>

(the same of the comment #0 but without double quotes), the part after the comma get immediately lost.
Philipp, what should be the behavior in this case?

I've uploaded a build for Windows if someone what to try it:
http://www.mediafire.com/file/89bfcnud1akp317/lightning1.0b3pre-20110208-Bug492069-Win.xpi
try it only on a *new profile* and *without* important data. ;-)
Attachment #510643 - Flags: review?(philipp)
Assignee: nobody → bv1578
Status: NEW → ASSIGNED
We had the same problem on Linux using Thunderbird 3.1.7 & 3.1.9 with Lightning 1.0b2.

The patch posted in comment 17 works for us, too.

Please apply this patch to upstream!!
Having the same problem with Lightning 1.0b2 and TB 3.1.9 on Win7. Also because I'm using the surname, firstname format.
I have the same problem with Lightning 1.0b2 and Postbox 2.1.4
Attachment #510643 - Attachment description: patch based on Maciej's code → [for beta]patch based on Maciej's code
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/ceb7dae0c311>
-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Comment on attachment 510643 [details] [diff] [review]
[for beta]patch based on Maciej's code

Oh, did I say r=philipp? ;-)

I have a followup patch that mimics the behavior of Thunderbird when a comma is entered. I'll upload in a moment.
Attachment #510643 - Flags: review?(philipp) → review+
Backported to comm-miramar <http://hg.mozilla.org/releases/comm-miramar/rev/a7074bcee258>
Target Milestone: Trunk → 1.0b4
Followup bug 658015 filed with a patch, I'd appreciate if you could look into it.
Target Milestone: 1.0b4 → Trunk
Backported to comm-miramar <http://hg.mozilla.org/releases/comm-miramar/rev/ade521240e4f>
Target Milestone: Trunk → 1.0b4
You need to log in before you can comment on or make changes to this bug.