Closed
Bug 437645
Opened 16 years ago
Closed 16 years ago
error reading a remote calendar
Categories
(Calendar :: Provider: ICS/WebDAV, defect)
Tracking
(Not tracked)
VERIFIED
INVALID
People
(Reporter: bmillett, Unassigned)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5 Build Identifier: lighting 0.9pre build 2008060418 This is very strange. I can take the ics file and load it into a local lightning calendar and it works fine. I can export the lightning calendar as an ics file and load it into the remote calendar (WebCalendar v1.2.b1 (25 Feb 2008)) and it works find using the webcalendar web interface. I try to subscribe to the calendar remotely, and I get the following error reading from the remote interface. I export the calendar from webcalendar and I cannot load that export into lightning. I get the same error below: Error: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [calIIcalComponent.endTime]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: file:///home/bpm/.thunderbird/default/e4xceiin.slt/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js :: anonymous :: line 553" data: no] Source File: file:///home/bpm/.thunderbird/default/e4xceiin.slt/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calItemBase.js Line: 553 Reproducible: Always Steps to Reproduce: 1.subscribe to remote calendar 2.refresh calendar 3.read error I can send the two ics files. 1) that loads into lightning and 2) export of (1) from webcalendar, but I do not see howto.
Reporter | ||
Comment 1•16 years ago
|
||
first ics file
Reporter | ||
Comment 2•16 years ago
|
||
This is the file that causes the error.
Updated•16 years ago
|
Attachment #324062 -
Attachment mime type: text/calendar → text/plain
Updated•16 years ago
|
Attachment #324064 -
Attachment mime type: text/calendar → text/plain
Updated•16 years ago
|
Component: Lightning Only → Provider: ICS/Webdav
QA Contact: lightning → ics-provider
Summary: error reading a remote calendar. → error reading a remote calendar
Comment 3•16 years ago
|
||
Both .ics file fail on the iCalendar Validator <http://severinghaus.org/projects/icv/>. The errors occurs on events like (from attachment 324064 [details]): BEGIN:VEVENT UID:20080504T0001004645109@lds.org LAST-MODIFIED:20080529T031702Z SUMMARY:Elder Russell M. Nelson DESCRIPTION:Elder Russell M. Nelson CATEGORIES:Branch Event CLASS:PUBLIC STATUS:CONFIRMED ATTENDEE;ROLE=OWNER;PARTSTAT=ACCEPTED:Brian Millett <xxx@yyy.zzz> DTSTART;TZID=America/Chicago:20080504T000000 DTSTAMP:20080529T121243Z DTEND;VALUE=DATETIME:20080505T000000 END:VEVENT The line that causes the failure is DTEND;VALUE=DATETIME:20080505T000000 The line doesn't exist in the first file (attachment 324062 [details]) and has been added by WebCalendar application. I think this is invalid according to RFC2445. The correct entry should be DTEND;VALUE=DATE-TIME:20080505T000000
Reporter | ||
Comment 4•16 years ago
|
||
Very NICE! I fixed the webcalendar code found in xcal.php. I changed the DATETIME to be DATE-TIME and it now works. Interesting in that in the xcal code there is this comment: // All times are now stored in UTC time, so no conversions are needed // other than formatting // // NOTE: Forcing the DTEND to include a 'T000000' as a DATETIME rather // than just a DATE is needed to avoid a bug in Sunbird 0.7. If the // DTSTART has a DATETIME and the DTEND is just DATE, then Sunbird locks up. I'll notify the webcalendar people. Thanks!! So very fast! You might want to have a bit of an ability to see just what line it did croak on, or what data structure, not just the js line.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Resolution: FIXED → INVALID
Comment 5•16 years ago
|
||
Corresponding WebCalendar bug report: https://sourceforge.net/tracker/index.php?func=detail&aid=1960454&group_id=3870&atid=103870
Reporter | ||
Comment 6•16 years ago
|
||
Looks like they took a different approach to solve it. The cvs co of the 1.2 branch shows that they just are going to use DATE. $ret .= "DTEND;VALUE=DATE:$date\r\n"; Thanks for the quick reply.
You need to log in
before you can comment on or make changes to this bug.
Description
•