User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:126.96.36.199) Gecko/20091211 Sunbird/1.0b1 It causes problems with vcs files that have been decoded from utf8 quoted-printable Reproducible: Always Steps to Reproduce: 1. Try to import the attached files 2. If properly imported try to delete them 3. See that some steps are not completed
iCalendar files must be encoded in UTF-8 character encoding format. You files are in ANSI character encoding format and therefore Lightning reports a CAL_UTF8_DECODING_FAILED error. Solution: Open the files in a text editor and change the encoding from ANSI to UTF-8. Now opening and import works fine.
But if I am a user, how would I know that? Shouldn't sunbird autodetect file codification? Is that all ICS files are UTF-8 encoded by default except mine? Google calendar does import correctly those files, so I think modifying the files is not the right approach.
Agreeing with comment #4, particular for remote calendar subscriptions that are updated beyond my control. And especially particularly, for calendars that just add new events without discarding old ones: if one old event had a buggy character, the entire calendar is useless forever until that old and already-happened event is discarded! At the very least, the calendar error message (Lightning 1.0b5 for me) is utterly unhelpful in pinning down what the problem character is. Several mitigations come to mind: * Attempt to change the encoding automatically. According to comment #3 and http://forums.mozillazine.org/viewtopic.php?p=10920755#p10920755, that seems to be against Lightning's policy...but if it's really so easy to just "open the files in a text editor and change the encoding from ANSI to UTF-8", I'd much rather Lightning do that for me, and leave a warning note in the error log. * Discard all events that occurred in the past, and only report errors if upcoming events have malformed characters. Particularly for remote read-only calendars, where the calendar user has no hope of fixing the bug himself. * Discard only those messages for which the characters cannot be correctly decoded, while leaving the other messages intact. This is an awkward approach, since it drops some information and preserves others, but has the advantage of the calendar not appearing completely broken. I'm sure there are other heuristics that could be useful, but the current standards-stickler approach seems to be the least useful, even if it's the most correct.