283881 - Incompatibility with Apple Mac iCal client [bad line ends in wrapped long descriptions]

Status: VERIFIED FIXED

(Calendar :: Internal Components, defect)

Description

[Carl Seibert]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 7.53  [en]
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20050203 Mozilla Sunbird/0.2

Events written to a published calendar (on icalx.com) by Sunbird (Linux) or Thunderbird Mozilla 
Calendar (Windows 2000, Mac OS 10.3) do not appear on that calendar when read By the 
Macintosh iCal application (1.5.5-v670). Further, when the Mac application refreshes, it overwrites 
the calendar on the server, effectively any events written by the Mozilla products. Events written by 
the Mac app are read properly by the Mozilla app, regardless of platform, and publishing works 
correctly Mozilla app to Mozilla app, regardless of platform. I don not think this is due to 
idiosyncracies at icalx.com - see also the "Holidays" bug that I'll file in a moment.

Reproducible: Always

Steps to Reproduce:
1. Publish events to server on Mozilla Calendar
2.View calendar on Macintosh. Write another test event on Mac.
3.View calendar on Mozilla Calendar. 

Actual Results:  
As above- events written on Mozilla Calendar won't appear in Mac iCal. Events written by Mac will 
appear in Mozilla Calendar. After refresh on Mac, Mozilla-written events will be deleted from 
calendar as seen by Mozilla clients.

Expected Results:  
Changes written by either applications should read in the other. That simply subscribing to a 
calendar with Mac iCal deletes all Mozilla-written entries exacerbates impact.

Somebody has strayed from the standard. Quite possibly, this could be a bug in the Mac 
application, although the "Holidays" bug suggests that it might be addressable from the Mozilla side 
in any case.

Comment 1

[Aaron Pulkka]

We have some ics files that we created using Sunbird 0.2 on Windows, that we
have been sharing via WebDav using Sunbird on Windows and MacOS X. 
Unfortunately, if we try to open these same files using iCal on MacOS X, the
operation fails during load (not a valid calendar file).  I removed all TODO
items by hand (since we have been having problems with these in Sunbird anyway),
so there are only recurring and one-time events in the ics files.

Comment 2

[gekacheka]

Does Apple iCal accept the file exported by sunbird?   (select only the calendar
in the calendars tab, select all events in the events list. then file | export
selected events) 

Exporting does a little end-of-line cleanup.  Long descriptions have incorrect
line ends (\n instead of \r\n).

Comment 3

[Aaron Pulkka]

Yes, selecting all events, then exporting to an .ics file does generate a file
that iCal is happy to load without error.  

Now if only it was always exported that way when it was published to the WebDav
server...

Comment 4

[gekacheka]

Reduced from critical to normal, has very inconvenient workaround (either use
short 1-line descriptions, or export then publish by other means, such as manual
ftp).

iCalendar RFC2445 standards issue, blocking bug 129660.

I assume this is a libical issue, as I think that is where RFC2445 format is
generated.  

Searching for "75 char", it looks like ical_property_as_ical_string folds lines 
http://lxr.mozilla.org/seamonkey/source/calendar/libical/src/libical/icalproperty.c#545
using fold_property_line
http://lxr.mozilla.org/seamonkey/source/calendar/libical/src/libical/icalproperty.c#341
which seems to use the ICAL_UNIX_NEWLINE switch correctly like everything else.

(However this file was added 2005.01.05, so it wasn't part of the 0.2rc
releases, so the 0.2 final release might be using an older version.  If so, this
bug might be fixed simply by recompiling with the new version.) 

Comment 5

[Joey Minta]

Any reason to keep this bug open?  As gekacheka pointed out, it should have been fixed with the newer file.  Everyone at the CalConnect inter-op handled our files without a problem.

Comment 6

[gekacheka]

Looks fixed to me.  The wrapped line ends are now CRLFs in both file:///temp.ics and exported files.  
(Note: wrapped line ends are introduced to wrap a long value to 75 chars in the ics file.  New lines IN the value are encoded as two characters in the value, so each newline appears as a literal '\' then 'n' in the value.)

Comment 7

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!