Since upgrading to Thunderbird 102.2.2 I've been experiencing long annoying pauses which sometimes go on for minutes but are usually in the 10-15 seconds range. I managed to capture a profile of one these hangs and it seems to be happening in the calendar code, possibly sorting dates:

https://share.firefox.dev/3Qu4goQ

gsvelto, Can you narrow this down to a specific aspect (type of calendar event) of a specific calendar?

A specific slice is https://profiler.firefox.com/public/phq3efb38de2ejnyw426285vm2d54b9kyb2afkg/calltree/?globalTrackOrder=0w3&hiddenGlobalTracks=1w3&hiddenLocalTracksByPid=25213-0we&implementation=js&range=16152m17898&thread=0&v=7

As a workaround you can try setting calendar.icaljs to false.

(In reply to Wayne Mery (:wsmwk) from comment #1)

gsvelto, Can you narrow this down to a specific aspect (type of calendar event) of a specific calendar?

A specific slice is https://profiler.firefox.com/public/phq3efb38de2ejnyw426285vm2d54b9kyb2afkg/calltree/?globalTrackOrder=0w3&hiddenGlobalTracks=1w3&hiddenLocalTracksByPid=25213-0we&implementation=js&range=16152m17898&thread=0&v=7

I have a single Google calendar setup for my @mozilla.com account, and nothing else. Over the years it has accumulated a lot of events, probably hundreds of them.

This seems to be happening while the calendar syncs. If I force a sync by hand I immediately get a hang.

(In reply to Magnus Melin [:mkmelin] from comment #2)

As a workaround you can try setting calendar.icaljs to false.

I've changed that pref and indeed I experience no pauses anymore.

Lasana, Sean,
Is comment 1's profile sufficient information to attempt a fix?

The profile suggests to me that something has a date very far in the future. Most of the time is spent in ICAL.Timezone._ensureCoverage which would be problematic if the argument was a high value, e.g. if an extra digit was accidentally added. I've never seen a profile with jank in this function before.

Hmm, that function stops at the year 2035. So my previous comment is quite likely invalid.

I have a set of recurring events which have no end date AFAIK, maybe that could be related?

I seem to be experiencing the same problem with version 102.2.2. I have uploaded a performance profile at https://share.firefox.dev/3RXmGzu. The issue is apparent in the 30" interval at its end with 100% CPU load. The culprit seems to be icaltimezone_compare_change_fn.

• The freezes occur every 60" and last for about 110".
• I don't think I'm auto-synchronizing with an external calendar.
• The freezes also occur in Safe Mode.
• Setting calendar.icaljs to false seems to stop the problem after restarting Thunderbird.
• My exported calendar is about 4MB large containing about 6000 VEVENT entries and 50 TODO items.

I went through the file looking for entries that could be triggering the behavior. One thing that struck me was numerous birthday entries with DTSTART/DTEND in 2037, as in the following example. Not sure if this is normal.

BEGIN:VEVENT
CREATED:20220727T213505Z
LAST-MODIFIED:20220912T071006Z
DTSTAMP:20220912T071006Z
UID:17cdb7a4-4579-4985-8523-979a07e99fc3
SUMMARY:John Doe. Birthday
RRULE:FREQ=YEARLY;UNTIL=20361231
DTSTART;TZID=Europe/Athens;VALUE=DATE:20370101
DTEND;TZID=Europe/Athens;VALUE=DATE:20370102
CLASS:PUBLIC
END:VEVENT

(In reply to Gabriele Svelto [:gsvelto] from comment #9)

I have a set of recurring events which have no end date AFAIK, maybe that could be related?

So do I, and no problem here. I wouldn't expect

Could you increase the value of ICAL.Timezone.MAX_YEAR (either by changing the code in a local build or importing resource:///modules/calendar/Ical.jsm) and see what happens? I found a way to trigger a similar slowdown, and increasing the value helped. It'd also be interesting to know what value _ensureCoverage is being called with.

I can try making a local build and seeing if I can repro.

https://www.reddit.com/r/Thunderbird/comments/x39f0n/comment/iog68a1/?utm_source=reddit&utm_medium=web2x&context=3 also has a performance profile https://share.firefox.dev/3L7MZAJ

Sharing something that might be useful: my wife's Thunderbird installation has no calendars configured yet the workaround in comment 2 made the problem go away. This user on Reddit also mentioned he doesn't have any calendars but the workaround seems to have helped. This seems quite odd, doesn't it?

I made a build of Thunderbird 102.2.2 with the value changed, if you wish to try them:

• Linux https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/E8rQEBpnRASVhT-88ZJYmQ/runs/0/artifacts/public/build/target.tar.bz2
• Mac https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Tq_eRplrQFu4Sh45FKLi0g/runs/0/artifacts/public/build/target.dmg
• Windows https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/fWhh3289Qf2eHiAd_cEClw/runs/0/artifacts/public/build/target.zip

It seems very odd that no calendars configured would cause this. It suggests there might be something in the UI trying to do something beyond 2035, which wouldn't really surprise me but I don't know what it could be. I was able to make some things very slow just by pushing the date past 2035 and that is cleared up by this change. If somebody can get a full stack trace of the function acting slowly that would be a great help, even if we can solve the problem by changing the maximum year.

Okay, I now understand why this function is being called so often even though 2035 is a long time from now. I also don't see any downside to removing the maximum year constraint.

This code doesn't do anything except avoid necessary calculation, and because the calculation isn't done the expensive part of the function is called over and over again.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/6a451262bdac
Remove MAX_YEAR constant for expanding timezones. r=mkmelin

Possibly a dupe of bug 1780973?

(In reply to Arthur K. (he/him) from comment #19)

Possibly a dupe of bug 1780973?

Does the try build or current beta 106 solve it?

gsvelto, does the try build help you?

And,....

(In reply to Gabriele Svelto [:gsvelto] from comment #14)

Sharing something that might be useful: my wife's Thunderbird installation has no calendars configured yet the workaround in comment 2 made the problem go away.

Does the try build help that situation also? If not, please create a new bug report with a profile. Thanks

(In reply to Wayne Mery (:wsmwk) from comment #20)

(In reply to Arthur K. (he/him) from comment #19)

Possibly a dupe of bug 1780973?

Does the try build or current beta 106 solve it?

Sadly, no. I'm in the midst of trying to capture a perf profile to add to 1780973 but TB's locked up good.

I managed to capture a perf profile over in bug 1780973 (https://share.firefox.dev/3dw9x1x) in case there's a relationship to this bug.

Is this something that needs to/should be brought upstream to ical.js?

Comment on attachment 9295208 [details]
Bug 1789999 - Remove MAX_YEAR constant for expanding timezones. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #): ical.js
User impact if declined: big perf impact if dealing with dates beyond 2031
Testing completed (on c-c, etc.): in 106.0b1
Risk to taking this patch (and alternatives if risky): low

(In reply to Martin Schröder [:mschroeder] from comment #24)

Is this something that needs to/should be brought upstream to ical.js?

Yes, but all PRs there are being blocked by the ES6 work so I haven't done it yet. Leaving the NI.

Sorry for the delay, I tried the build in comment 15 and I can confirm that the problem is gone! \o/

Comment on attachment 9295208 [details]
Bug 1789999 - Remove MAX_YEAR constant for expanding timezones. r=#thunderbird-reviewers

[Triage Comment]
approved for esr102

This patch needs a follow-up to set the upstream source comment to mention the pull request at https://github.com/kewisch/ical.js/pull/541.

Thunderbird 102.3.2:
https://hg.mozilla.org/releases/comm-esr102/rev/7dd3014487f0

Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/4353e8935d04
Follow-up: Include PR information in reference to upstream source. r=darktrojan

Comment on attachment 9297188 [details]
Bug 1789999 - Follow-up: Include PR information in reference to upstream source. r=darktrojan

[Triage Comment]
Documentation only fix for Ical.jsm upstream information.

Thunderbird 106.0b5:
https://hg.mozilla.org/releases/comm-beta/rev/6a5695bc11f8

Thunderbird 102.3.2+ (102.4.0?)
https://hg.mozilla.org/releases/comm-esr102/rev/8d8b229caa5e