Closed Bug 1773571 Opened 6 months ago Closed 2 months ago

TypeError: null has no properties - Ical.jsm:5519:26- for invitation to an event in a time zone that calendar doesn't recognise

Categories

(Calendar :: ICAL.js Integration, defect)

Thunderbird 102
defect

Tracking

(thunderbird102+ affected)

RESOLVED DUPLICATE of bug 1791038
Tracking Status
thunderbird102 + affected

People

(Reporter: rachel, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

See enclosed screenshot.

Blocks: tb102found

Perhaps side effect of bug 1760805?

libical handles the case without the extra noise.

Still seen in TB 102 beta 7 which includes the fix for bug 1760805.

Summary: TypeError: null has no properties - Ical.jsm:5519:26 → TypeError: null has no properties - Ical.jsm:5519:26- for invitation to an event in a time zone that calendar doesn't recognise

Could you please provide reproduction steps for this issue?

Flags: needinfo?(rachel)

Sorry, no, we just start TB 102 beta on an existing profile. Apparently the calendar data isn't to the liking of IcalJS. There is no error when using libical.

Flags: needinfo?(rachel)

I suspect this lies in events stored in local calendars, but I have been unable to reproduce. Until any sort of reproduction steps can be provided, I'm unable to proceed with work on this.

Flags: needinfo?(neil)

Due to this error, we weren't using ICaljs (pref calendar.icaljs) for a while until we noticed that the "Today pane" doesn't work any more with libical.

So we finally got around to debugging this. The issue was that zone was passed in as null here:
https://searchfox.org/comm-central/rev/8c1e764a0db62df49c974641013482f4ae5d9c6d/calendar/base/modules/Ical.jsm#5511

Inspecting the database with the SQLite-Browser we found this data in cal_events.event_start_tz and cal_events.event_end_tz:

BEGIN:VTIMEZONE
TZID:(GMT+01.00) Sarajevo/Warsaw/Zagreb
X-MICROSOFT-CDO-TZID:2
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE

So instead of just the TZID Sarajevo/Warsaw/Zagreb, the entire definition of the timezone was stored in the DB field. We don't know how that happened.

The timezone ID (GMT+01.00) Sarajevo/Warsaw/Zagreb isn't one of the standard timezone IDs from the IANA timezone database, so we don't recognize it and have to store the full definition instead. This seems to confirm my suspicions of what's happening here and I believe this is the same as another bug I'm working on.

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → DUPLICATE
Flags: needinfo?(neil)
You need to log in before you can comment on or make changes to this bug.