The following fails in TB 40.0a2 (2015-06-12) with Lightning 4.2a2 and Tb 42.0a1 (2015-07-02) (today's daily) with Lightning 4.4. Import the attached file. It has two events. One "Get stuff" is on the 4th of the month, repeating monthly. The second one "Update stuff" is on Tuesdays, repeating weekly. When importing, the first event is placed onto the 1st of the month. The second event is imported correctly. However, when closing Daily and reopening it, the weekly event is broken. It is not shown in the calendar. When opening it (all occurrences), it now shows a custom daily (!) reoccurrence.

Showing on the 1st of the month is known problem with new icaljs library (Bug 1103187). Can you retest and check if everything works correctly after setting "calendar.icaljs" to false?

Damn, I had e-mail Fallen to ask before submitting the bug, but got no quick reply. Both events work fine with the setting you suggested.

Actually, looking at it a little closer: Bug 1103187 is about monthly events. I have a weekly event that's broken. So I'm reopening this bug.

Confirming the broken weekly event on current Daily. This behaviour appears only, if the import was done with icaljs enabled. If using libical for import, the event gets displayed also after repeated restart with icaljs. When using icaljs, after restarting the following error messages appear: Timestamp: 05.07.2015 12:15:12 Error: Error: Could not extract integer from ":0" Source File: resource://calendar/modules/ical.js Line: 92 Timestamp: 05.07.2015 12:15:12 Error: [calStorageCalendar] Message: Error getting recurrence for item 'Update stuff' (xx6ff04e-2558-4d9b-bbb6-e14b342a97d1)! Connection Ready: true Last DB Error Number: 100 Last DB Error Message: unknown error Database File: F:\TB-Testprofile\commcentral\calendar-data\local.sqlite Last DB Statement: [object StatementJSHelper] Last Statement param [item_id]: xx6ff04e-2558-4d9b-bbb6-e14b342a97d1 Last Statement param [cal_id]: f0326b9a-d56a-4390-a898-6e594e5f3e8f Last Statement param [QueryInterface]: function QueryInterface() { [native code] } Exception: [Exception... "[JavaScript Error: "Could not extract integer from ":0"" {file: "resource://calendar/modules/ical.js" line: 92}]'[JavaScript Error: "Could not extract integer from ":0"" {file: "resource://calendar/modules/ical.js" line: 92}]' when calling method: [calIRecurrenceRule::icalProperty]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "JS frame :: file:///F:/TB-Testprofile/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js :: cSC_getRecurrenceItemFromRow :: line 1881" data: yes] 1: [file:///F:/TB-Testprofile/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js:2416] cSC_logError 2: [file:///F:/TB-Testprofile/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js:1746] cSC_getAdditionalDataForItem 3: [file:///F:/TB-Testprofile/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js:1605] cSC_getEventFromRow 4: [file:///F:/TB-Testprofile/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js:1552] cSC_assureRecurringItemCaches 5: [file:///F:/TB-Testprofile/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js:720] cSC_getItems_ 6: [file:///F:/TB-Testprofile/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js:662] cSC_getItems/< 7: [null:0] null Source File: file:///F:/TB-Testprofile/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js Line: 2416 I don't have the custom rrule, but comparing orginal and current ics after opening the event dialog, I see RRULE:FREQ=WEEKLY;UNTIL=20160118T070000Z instead of RRULE:FREQ=WEEKLY;UNTIL=20160118T170000Z, which is an offset of 10 hours and at least would let dispappear the last occurence. Also this triggers the save/don't save dialog even if the event was not changed by the user when closing with X. Last but not least: As with bug 1179842, the event does appear after restart, if you open the ics as a new calendar instead of importing it (the rrule issue mentioned above applies on both scenarios and also when using libical, so it is a separate issue with the dialog). For the issue with monthly event, there is already bug 1103187, so let's keep this for the weekly one only. I change the summary accordingly, if you don't mind.

(In reply to MakeMyDay from comment #4) > I change the summary accordingly, if you don't mind. Of course I don't. Thanks for looking at it.

Doing this again with 42.0a1 (2015-07-05) and icaljs set to true: Import the attached file. "Update stuff" event occurs every Tuesday as it should. Do not visit the event. Do not open it. Restart TB. "Update stuff" event has disappeared. Go to Jan 2015. On the 27th of Jan 2015, edit all occurrences of the event, see attached. Export the calendar, the event gets exported as without RRULE: BEGIN:VEVENT CREATED:20150120T201548Z LAST-MODIFIED:20150630T062502Z DTSTAMP:20150630T062502Z UID:xx6ff04e-2558-4d9b-bbb6-e14b342a97d1 SUMMARY:Update stuff X-MOZ-LASTACK:20150630T062502Z DTSTART;TZID=Europe/Berlin:20150127T080000 DTEND;TZID=Europe/Berlin:20150127T090000 TRANSP:OPAQUE X-MOZ-GENERATION:31 BEGIN:VALARM ACTION:DISPLAY TRIGGER:-PT15M DESCRIPTION:Default Mozilla Description END:VALARM END:VEVENT

As MakeMyDay wrote in comment 4, I think we have to open a different bug about the behavior of the Edit Dialog (and the recurrence dialog as well), instead the different behavior about ical.js and libical is caused by the different format used by ical.js and libical to store the recurrence in the database. The kind of recurrence doesn't matter (the monthly recurrence in the calendar test is an infinite rule i.e. without until date). With libical the format is: RRULE:FREQ=WEEKLY;UNTIL=20160118T170000Z with ical.js: RRULE:FREQ=WEEKLY;UNTIL=2016-01-18T17:00:00Z I had written a patch but I've found out that Geoff Lankow has already done a great (and more complete) work here: https://github.com/mozilla-comm/ical.js/pull/198 that fixes the issue, so it's only matter to wait for a review on GitHub and to pull the latest version of ical.js from GitHub. I've changed the summary to the same of the issue #197 on GitHub https://github.com/mozilla-comm/ical.js/issues/197

So this bug is another candidate for closure due to refreshing ical.js (bug 1115667). I'll test it soon.

Would it be possible to create an (xpcshell) unit test for this problem, to ensure that it a) works now and b) can't regress in the future?

(In reply to Jorg K (GMT+2) from comment #8) > So this bug is another candidate for closure due to refreshing ical.js (bug > 1115667). Issue #197 https://github.com/mozilla-comm/ical.js/issues/197 is still open. Currently only the first issue in comment 0 is fixed.

Bug 1483638 is about to land, and while it won't actually fix the parsing of incorrect dates, it will stop putting them in the database. We could use the database-schema-update mechanism to clean up the databases, but I think the number of occurrences is likely to be very, very small, so I don't think it's worth it. Unless someone objects, I'll close this bug after bug 1483638 lands.