1849849 - Error when parsing Apple iCloud calendars (Error: Could not extract integer from ":3")

Status: UNCONFIRMED

(Calendar :: ICAL.js Integration, defect)

Description

[Daron Brewood]

Attachment: 07bug - console-export-2023-8-23_13-37-52.txt

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36

Steps to reproduce:

Just subscribe to any of my iCloud calendars, and then open TB, these error messages are shown. The issue occurs when using native calendar addition in TB as well as with TBSync.
If needed I can provide temporary private access to one of my calendars to assist in resolving the issue.

Actual results:

The console reports errors such as:
13:37:39.380 Calendar: Error: Could not extract integer from ":3"
    strictParseInt resource:///modules/calendar/Ical.jsm:156
    fromDateTimeString resource:///modules/calendar/Ical.jsm:6076
    fromString resource:///modules/calendar/Ical.jsm:6100
    set icalString resource:///modules/CalDateTime.jsm:200
    createDateTime resource:///modules/calendar/calUtils.jsm:30
    set icalComponent resource:///modules/CalAlarm.jsm:559
    set icalString resource:///modules/CalAlarm.jsm:363
    CalAlarm resource:///modules/CalAlarm.jsm:38
    getAdditionalDataForItemMap resource:///modules/calendar/CalStorageItemModel.jsm:652
    handleResultInner resource:///modules/calendar/CalStorageDatabase.jsm:236
CalStorageDatabase.jsm:250

Expected results:

No errors reported

Comment 1

[Martin Schröder [:mschroeder]]

Daron, there are possibly event entries which can not be parsed because of malformed date or date time data.

Comment 2

[Daron Brewood]

I’m away at the moment but can give you access to one of the problematical calendars when I get home. I’d want to pass those details on privately. Would that help? No other applications I use the calendars with have issues with the calendars.

Comment 3

[Daron Brewood]

Hi Martin we're now back from holiday, can you please contact me directly so I can give you details of one of the problematic calendars so you can investigate?
No other calendar application I have used on the Mac (Apple Calendar, Fantastical, BusyCal) has any issues with reading / writing to the iCloud calendars.

Comment 4

[betterbird.project+11]

We debugged this a bit. Looks like some alarm date/times contain, for example, 2023-04-24T13:41:55Z which gets transformed into 2023--0-4-T4T:13::4 which is then unsuccessfully parsed. The correct input would be 20230424T134155Z. We're looking further where that data comes from. Of course it's not imported since the parsing fails. In any case, error reporting should be greatly improved since Could not extract integer from ":4" is not helpful.

Comment 5

[betterbird.project+11]

If we add this code

  set icalString(val) {
    let jcalString;
    if (val.length > 10) {
      if (/-.*-.*:.*:/.test(val)) {
        console.log(`=== Found value ${val}, not processing via ICAL`);
        jcalString = val;
      } else {
        jcalString = ICAL.design.icalendar.value["date-time"].fromICAL(val);
      }
    } else {
      jcalString = ICAL.design.icalendar.value.date.fromICAL(val);
    }
    this.innerObject = ICAL.Time.fromString(jcalString);
  },

here https://searchfox.org/comm-central/rev/f54fce038921a7a7011a68e7ad9c3e2d6691ad17/calendar/base/src/CalDateTime.jsm#196, we see this in the console:

=== Found value 2023-10-09T12:51:27Z, not processing via ICAL

It looks like the alarm is properly imported into the TB Calendar and can also be exported resulting in:

BEGIN:VALARM
ACTION:AUDIO
TRIGGER:-PT5M
ATTACH:Basso
X-MOZ-LASTACK:2023-10-09T12:51:27Z
UID:943F6ECB-41F9-4CED-8DFD-7DF31C54E15A
X-BUSYMAC-DEFAULT-ALARM:TRUE
ACKNOWLEDGED:20231009T125127Z
END:VALARM

Surprising is the X-MOZ-LASTACK:2023-10-09T12:51:27Z. This format occurs 16 times in the calendar matching the number of console messages. Other dates in the exported ICS file have this format X-MOZ-LASTACK:20230822T142704Z.

So somehow two different formats are used for the X-MOZ-LASTACK attribute and one throws the parser off the rails.

Comment 6

[betterbird.project+11]

console.trace() === Found value 2023-04-24T13:41:55Z, not processing via ICAL 2 CalDateTime.jsm:197:17
    set icalString resource:///modules/CalDateTime.jsm:197
    createDateTime resource:///modules/calendar/calUtils.jsm:33
    set icalComponent resource:///modules/CalAlarm.jsm:559 <<--- this line here
    set icalString resource:///modules/CalAlarm.jsm:363
    CalAlarm resource:///modules/CalAlarm.jsm:38
    getAdditionalDataForItem resource:///modules/calendar/CalStorageItemModel.jsm:973
    handleResultInner resource:///modules/calendar/CalStorageDatabase.jsm:236
    handleResult resource:///modules/calendar/CalStorageDatabase.jsm:230

This is in version 115. Interesting code here:
https://searchfox.org/comm-esr115/source/calendar/base/src/CalAlarm.jsm#556-559

    // Set up the alarm lastack. We can't use valueAsDatetime here since
    // the default for an X-Prop is TEXT and in older versions we didn't set
    // VALUE=DATE-TIME.
    this.lastAck = lastAckProp ? cal.createDateTime(lastAckProp.valueAsIcalString) : null;

The comment suggests some incompatibility with "older versions".

Comment 7

[betterbird.project+11]

https://github.com/Betterbird/thunderbird-patches/blob/main/115/bugs/1849849-tolerate-bad-X-MOZ-LASTACK.patch