Viewing particular Mails takes 5 seconds (hasprofile)
For a few days I'm having trouble with Asana mails (notification mails informing me about replies, comments, etc).
Clicking on the mail to view it freezes Thunderbird for a good 5 seconds while one CPU core spins at 100%. This only happens with Asana mails (or at least I haven't found any other problematic senders).
I guess it's a problem with validation or parsing of the mail's HTML content. But I don't know how to debug this.
I can't pinpoint exactly when it started happening, but it was around the time I've switched to the [new snap release track](https://support.mozilla.org/en-US/kb/channel-choices-thunderbird-snap-and-flatpak#w_snap-channel-changes-in-2026). But since this happens with Snap and Flatpak I think the culprit may be the 153.0 update.
Things I've tried:
- Clearing cache and msf files.
- Troubleshooting mode with add-ons disabled.
- Reinstallation. Creating new profile + importing old data.
- Switching from Snap to Flatpak
- Switching Message Body display to Plan Text or Simple HTML.
- Disabling HW acceleration.
- Checking console for suspicious output.
Anything I can do to create handle the problem or collect information for a proper bug report?
Geändert am von Wayne Mery
Alle Antworten (5)
I've asked Julian to email me a copy of a problem email.
I've sent the information.
On that note, I also found out that the freeze does not occur when selecting several of the emails at once. Likely because the messages only show a summary rather than the full contents. See screenshot for what I mean.
Problem still persists on 156.0
Unfortunately we are unable to reproduce. A performance profile would help. Instructions at https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance
Thanks for taking another look. I've sent you a firefox share link with a perf trace.
I can see most time is spent on g_dbus functions inside ShouldLinkify when parsing the body content. Particularly nsGIOService::GetAppForURIScheme which is called three times for a total of ~90% of execution time.
I ran a debugging session with Claude. What it found via dbus-monitor is that about 6000 SchemeSupported calls are made per mail preview.
On Ubuntu 24.04, these calls fail because SchemeSupported was added in a newer version of xdg-desktop-portal. I initially thought the issue would resolve itself with updating. But now I tried 26.04 with a sufficiently new portal version and the problem persists.
So it seems, for some reason, the bus is queried again and again.
Here's the Claude blob with some more information from the 24.04 run (where SchemeSupported failed):
``` Cause: uncached OpenURI.SchemeSupported failure, new D-Bus proxy per call
On sandboxed Thunderbird (Flatpak 156 and Snap) with xdg-desktop-portal 1.18.4 (OpenURI v3), nsGIOService::GetAppForURIScheme calls org.freedesktop.portal.OpenURI.SchemeSupported. The portal has no such method, so every call fails with UnknownMethod. Gecko then logs "SchemeSupported method not found, fallback to flatpak handler". It does not cache the failure and does not reuse the proxy. Each call runs g_dbus_proxy_new_for_bus_sync, which means GetNameOwner, StartServiceByName, GetAll and AddMatch/RemoveMatch. These are synchronous on the main thread.
Workaround: Setting widget.use-xdg-desktop-portal.mime-handler = 0 cuts the preview delay from several seconds to about 0.5 s.
Suggested fix: - Remember UnknownMethod (or the OpenURI interface version) after the first failure. - Cache the proxy. - Consider caching the result per scheme. ```
Geändert am von julian46
Sie müssen sich mit Ihrem Benutzerkonto anmelden, um auf Beiträge zu antworten. Bitte stellen Sie eine neue Frage, wenn Sie noch kein Benutzerkonto haben.