291717 - Need to handle UTF-8 when receving iMIP invitaitons

Status: RESOLVED INVALID

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Description

[Alon Bar-Lev]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050419 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050419 Firefox/1.0.3

The CalendarEvent.ics attachment is encoded in ANSI character set, the problem
is that when using a UNICODE oriented language like Hebrew the receipent gets junc.
If the CalendarEvent.ics was encoded using UNICODE character set there should be
no problem to use it in any language.

Reproducible: Always

Steps to Reproduce:
1.Install Thunderbird
2.Install Calendar extension.
3.Open calendar.
4.Create a meeting with hebrew title and description.
5.Select the meeting and choose to mail this meeting.
6.Accept the meeting notice that the title and description were converted to junc.

Actual Results:  
Hebrew encoded meetings are received as junc.

Expected Results:  
Hebrew encoded meetings should be received correctly.

Comment 1

[gekacheka]

Attachment: calendarMail.js patch to save attachment using UTF-8

(patch -l -p 2 -i file.patch)

Patch to use saveDataToFile (from importExport.js) instead of
saveCalendarObject so that attachment can be saved using the UTF-8 charset. 
Patch also removes saveCalendarObject because it is no longer used.

Tested on Moz1.8b1 with patched version of CalendarExtension 20050228.

Note: There remain other problems such as bug 173039 which may require adding
some spaces or newlines at the end of titles and descriptions.

Comment 2

[Alon Bar-Lev]

Thank you!

It seems to write the file correctly...
But it does not read it using UTF8...

I've looked at the sources inside calendar.jar searching for the place where the
attachement is read.
But I could not find it...
Can you find the place and fix it also?

I've found that in calendarManager.js there is explicit comment on the UTF8
stuff (Should it also be uncommented?)

-------------------------------------------------------
  var onResponse = function( CalendarData )
   {
      //save the stream to a file.
      //saveDataToFile( ThisCalendarObject.getAttribute(
"http://home.netscape.com/NC-rdf#path" ), CalendarData, "UTF-8" );
       saveDataToFile( ThisCalendarObject.getAttribute(
"http://home.netscape.com/NC-rdf#path" ), CalendarData, null );

      if( onResponseExtra )
         onResponseExtra();
-------------------------------------------------------

Comment 3

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 181722 [details] [diff] [review]
calendarMail.js patch to save attachment using UTF-8

This code looks obsolete. saveDataToFile() is in importExport.js, which isn't included anymore.

Comment 4

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 5

[Martin Schröder [:mschroeder]]

Is this bug still valid?

Comment 6

[Alon Bar-Lev]

I don't use this product anymore... I use KOrginazer, which works perfectly wiht UTF-8.

Comment 7

[cmtalbert]

Alon, thanks for the response.  This code has been removed from the product, but I still see a few places where we can improve UTF-8 handling.

1. Send an invitation with UTF-8 characters (using Lightning, for now)
2. Receive the invitation in Lightning and view the created HTML bit of the message: this part will have corrupted the UTF-8 characters, even though they show up fine elsewhere in the application. Due to that corruption, the event is still corrupted when it is added to the calendar.

Comment 8

[Pedro Madeira]

The calendar (lightning) should create the CalendarEvent.ics retrieving the encoding used in Thunderbird to compose messages.

The problem that I have is that I use ISO 8859-1 to view and compose messages but the file that lightning builds is in UTF-8 so when I receive a mail notification the body of the email seems alright but the calendar event special characters are all unreadable until I switch the viewing character encoding to UTF-8 but this is not a solution as I want to view most of my mails as ISO 8859-1.

So if Lightning creates the attached event using the character encoding retrieved by Thunderbird composition all should be fine I think.

Comment 9

[Magnus Melin [:mkmelin]]

Pedro: that's bug 357172. (Though I'm not sure all of this bug is.)

Comment 10

[Pedro Madeira]

Thanks Magnus,

I copied paste my post into the other bug.

Comment 11

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(In reply to comment #7)
> Alon, thanks for the response.  This code has been removed from the product,
> but I still see a few places where we can improve UTF-8 handling.
> 
> 1. Send an invitation with UTF-8 characters (using Lightning, for now)
We cannot allow customization of the message due to compose API restrictions, so this part is no longer valid, correct?

> 2. Receive the invitation in Lightning and view the created HTML bit of the
> message: this part will have corrupted the UTF-8 characters, even though they
> show up fine elsewhere in the application. Due to that corruption, the event is
> still corrupted when it is added to the calendar.
This seems to work fine for me. I have an invitation with a couple of utf8 characters and they display fine in the message preview. Or did I misunderstand?

RESO INVALID, depends on 433848 ?

Comment 12

[Håvard Korsvoll]

Hi

I have found some misbehavior with events that have utf-8 characters in their title.

When an norwegian ø is placed after the 24th character in the title, the event is not parsed correctly by the receiver of the invite. I am using Thunderbird version 2.0.0.19 and lightning build 2008092321.

I will create two attachment where one is parsed correctly and one is not parsed correctly.

Comment 13

[Håvard Korsvoll]

Attachment: UTF-8 letter after the 24th letter in the title

Comment 14

[Håvard Korsvoll]

Attachment: UTF-8 letter before the 24th letter in the title

Comment 15

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Håvard, are you still having this issue with 1.0b1 ? We changed imip handling a lot since 0.9. Please reopen if this is still the case.