Full calendars published through Sunbird are invisible in iCal, but not other copies of Sunbird

RESOLVED DUPLICATE of bug 259956

Status

Calendar
Internal Components
--
major
RESOLVED DUPLICATE of bug 259956
14 years ago
12 years ago

People

(Reporter: Misha Syeed, Assigned: John Gray)

Tracking

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5 (KHTML, like Gecko) Safari/125.9
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040907 Mozilla Sunbird/0.2a

Every calendar I publish to a WebDAV server with Sunbird (or the calendar module for Mozilla-based 
browsers, for that matter) and then subscribe to via iCal does not behave properly. Sometimes the 
calendar appears, but events do not. If I subscribe to the same calendar via another copy of Sunbird or 
the calendar plug-in, all events appear. Sometimes, however, the published files is reported by iCal as 
being in an invalid format and is rejected. I have had similar results when physically double-clicking the 
.ics file created by Sunbird. It does not appear to matter whether it is Sunbird or the calendar plug-in, 
and it doesn't seem to matter which OS. I've tested with both versions of the program on Mac OS 
10.3.5, Windows 98 second edition, Windows ME, and Windows XP, on a variety of machines, all with 
the same results.)

I have had no problems in the other direction, that is I can subscribe to iCal calendars from Sunbird 
with no problems.

Reproducible: Always
Steps to Reproduce:
1. Create a calendar with several events in a libical based Mozilla calendar program.
2. Publish or export this entire calendar by right clicking on the calendar name.
3. Open iCal 1.5.2 (v637) and attempt to subscribe to the created calendar.
Actual Results:  
A calendar only usable by other copies of Sunbird or Mozilla calendar.

Expected Results:  
Created a calendar which appears identically in iCal and Sunbird.

Comment 1

14 years ago
This sounds similar to bug 259956, which was recently fixed in cvs.
Can you tell if the line ends have two carriage returns (\r\r\n instead of \r\n,
or in emacs some lines end with ^M^M)?
If you can edit the file and replace the carriage returns with one (with emacs,
alt-x replace-string ctrl-q ctrl-m ctrl-q ctrl-m ctrl-q ctrl-n enter   ctrl-q
ctrl-m ctrl-q ctrl-n enter), can iCal open the corrected file?  
(If so, this bug can be resolved as a duplicate.)
(Reporter)

Comment 2

14 years ago
Not quite -- this actually caused a reversion to an earlier version of this problem. When I first started 
using Sunbird, iCal could not read its published or exported files. The iCal error message when double-
clicking an ics file was:
         This calendar file unreadable. No events have been added to your calendar.
When importing the file with Sunbird, no events appeared, but if I stepped through each event during 
import, I was prompted for each event. I discovered that any event checked "private" was being 
imported by Sunbird, but not displaying. Unchecking "private" in the initial file solved this issue.

After trying a few things, suddenly iCal seemed to work and allowed me to subscribe, but no events 
appeared. I tried checking and unchecking private before publishing or subscribing to no avail -- iCal 
can't see them.

I went through and deleted every double-space (^M) in my ics file with emacs and now the initial iCal 
bad file warning is back, and Sunbird -- although it can see eight events -- imports them invisibly 
again, this time regardless of the private tag's setting.

Now here's the weird part -- I get slightly different results when publishing with Sunbird for Mac now: it 
works perfectly. I am at a loss to explain this, as I couldn't get it to function before. Even auto-
publishing works, which was guaranteed to corrupt the file before. I tried existing calendars and brand 
new ones -- all worked great. I have not changed my copy of Sundbird at all.

But I see no change in behavior on the PC side. Thoughts?

Comment 3

14 years ago
1. the ^M^M^J bug is a windows-only bug -- the windows version of the library
substitutes ^M^J for every ^J written by default, so it was set to binary mode.
 That explains why the Mac version works but the Windows version is broken.
2. The RFC2445 iCalendar spec says the line terminators are supposed to be ^M^J. 
3. Emacs accepts ^J as line terminator, or ^M^J as line terminators, but if
there is anything else it treats ^J as line terminator and shows the ^M's.  So
the ^M^M you saw at the end of each line is really for ^M^M^J, and should be
corrected to ^M^J.  In other words, the correct fix is to delete just one of the
^M's, not both.  That might be why iCal doesn't like it.
(Reporter)

Comment 4

14 years ago
That did it, thanks!

Comment 5

14 years ago

*** This bug has been marked as a duplicate of 259956 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE

Updated

12 years ago
QA Contact: gurganbl → libical
Component: libical → Internal Components
The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!
QA Contact: libical → base
You need to log in before you can comment on or make changes to this bug.