1783441 - ical files with FREEBUSY are no longer importable

Status: RESOLVED FIXED

(Calendar :: ICAL.js Integration, defect)

Description

[Laurence Tratt]

Attachment: bad.ics

Steps to reproduce:

Thunderbird used to be able to import ics files whose DTSTART did not have a timezone. Having just upgraded to v102 it is unable to import them. Here's an example I received from a booking site a couple of months ago:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Avvio//NONSGML Convert//EN
BEGIN:VEVENT
UID:4ABCDEF
DTSTAMP:20220531T190736Z
DTSTART;VALUE=DATE:20220606
DTEND;VALUE=DATE:20220608
SUMMARY:Blah blah.
FREEBUSY;FBTYPE=FREE:20220606/20220608
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR

Interestingly, not only did Thunderbird used to be able to import them, but it then copied them into my "main" calendar without adding a timezone. So I had a "merged" calendar which Thunderbird v102 refused to load. However, Thunderbird gave no indication as to why it wouldn't load -- there were just no calendar entries. I eventually managed to track down the offending error because py-icalendar couldn't parse that DTSTART value either!

Expected results:

IMHO the original ics file is incorrect, but since Thunderbird previously accepted it, there will be other people like me with an ics file that they assume is created by Thunderbird, but which has imported invalid value.

Ideally Thunderbird would at least explicitly complain to the user if it encounters an ics file it can't parse. In this (admittedly unusual) case of a missing timezone it could also either ask the user what timezone they want or (though this has obvious problems!) resort to the local timezone.

Comment 1

[Magnus Melin [:mkmelin]]

Not sure what/if there is an error in the data.
But I can reproduce: Error: Could not extract integer from ""

Comment 2

[Lasana Murray]

Importing this file works with File > Open > Calendar File and not through the import tool. That suggests to me they are using different code paths or maybe different parameters?

Comment 3

[Laurence Tratt]

I now think I pointed the finger at the wrong culprit: having bisected the input more carefully, the line that causes the Calendar import to choke is:

FREEBUSY;FBTYPE=FREE:20220606/20220608

Comment 4

[Laurence Tratt]

I've updated the bug title to something I hope is a bit more accurate!

Comment 5

[Lasana Murray]

The error happens because icaljs somehow ends up reading the period dates as yyyymmdd instead of yyyy-mm-dd when the non-async parsing is used. In parser._handleContentLine I see the strings are parsed correctly as yyyy-mm-dd but somewhere along the line it reverts to yyyymmdd. Furthermore, if you make a call to icalComp.toString() in the async route, you can trigger the error.

It seems like an icaljs bug but could also be caused by some of the complexity we have around iterating properties.

Comment 6

[Lasana Murray]

Attachment: Bug 1783441 - Remove X-LIC-ERROR handling in CalIcsParser.parseString. r=#thunderbird-reviewers

I'm not 100% sure the purposes of these checks serve but I beleive X-LIC-ERROR is a libical specific thing.
Calling toString() on an icaljs freebusy property seems to mess up the formatting of the period string.
This is likely a bug in icaljs but I was unable to track it down. Not calling toString() for the X-LIC-ERROR allows
us to avoid it though. Note also that the same check is not in the async branch of parseString.

Comment 7

[Magnus Melin [:mkmelin]]

Please make sure we have a but filed for the underlying issue.
I assume extending browser_import.js to cover the test case should also be trivial.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/eb799eb069a5
Remove X-LIC-ERROR handling in CalIcsParser.parseString. r=#thunderbird-reviewers,darktrojan

Comment 9

[Laurence Tratt]

I have applied the patch from https://hg.mozilla.org/comm-central/rev/eb799eb069a5 to 102.1.2 and can confirm that I can now import the file that caused the problem.

Thank you everyone for your help in fixing the problem -- it is much appreciated!

Comment 10

[Magnus Melin [:mkmelin]]

Lasana, we should uplift to 102, no?

Comment 11

[Lasana Murray]

Comment on attachment 9289745 [details]
Bug 1783441 - Remove X-LIC-ERROR handling in CalIcsParser.parseString. r=#thunderbird-reviewers

[Approval Request Comment]
User impact if declined: Users unable to import some ics files due to this bug.
Testing completed (on c-c, etc.): trunk, seems to be on beta already too.
Risk to taking this patch (and alternatives if risky): low risk

Comment 12

[Wayne Mery (:wsmwk)]

Comment on attachment 9289745 [details]
Bug 1783441 - Remove X-LIC-ERROR handling in CalIcsParser.parseString. r=#thunderbird-reviewers

[Triage Comment]
Approved for esr102

Comment 13

[Rob Lemley [:rjl]]

Thunderbird 102.3.3:
https://hg.mozilla.org/releases/comm-esr102/rev/226f24d845bc