1958931 - Donation and New Release tabs cause 100% CPU usage in --headless mode

Status: UNCONFIRMED

(Thunderbird :: General, defect)

Description

[Bruce Momjian]

Steps to reproduce:

I run Thunderbird in --headless mode. When I stop it via systemctl, upgrade it, and restart it, again in headless mode, if there is a new donation or new version tab added, Thunderbird usage goes to 100% CPU, I assume trying to display those new pages.

I think I might have fixed it by disabling the "Thunderbird Start Page" and removing the donation URL in the Config Editor, but I am not sure, and this should not be needed.

This is on Debian 12.

Actual results:

100% CPU usage on Thunderbird

Expected results:

Normal <5% CPU usage

Comment 1

[Wayne Mery (:wsmwk)]

Are you using the conversations addon?

Comment 2

[Bruce Momjian]

No, the only plugin I am using is the redirection one:

https://addons.thunderbird.net/en-us/thunderbird/addon/simple-mail-redirection/

In fact, I am using Thunderbird for redirection, which is why it is being used in --headless mode.

Comment 3

[Wayne Mery (:wsmwk)]

The start page should have nothing to do with this process.

Toby, has the appeal been be tested in headless mode?

Comment 4

[Toby Pilling [:tobyp]]

No we don't have much test coverage for --headless. I will add this to our list of enhancements that we have planned for IAN in the future.

For now, those two configuration settings should do the trick!

Comment 5

[Toby Pilling [:tobyp]]

I also expect that the changes to the in-app notification system in bug 1936324 would address the problem. This won't get uplifted to 128 but will be in ESR140 which is shipping today and also in our monthly release.

Comment 6

[Bruce Momjian]

(In reply to Toby Pilling [:tobyp] from comment #5)

I also expect that the changes to the in-app notification system in bug 1936324 would address the problem. This won't get uplifted to 128 but will be in ESR140 which is shipping today and also in our monthly release.

I am running Mozilla Thunderbird 140.4.0esr on Debian 13 and, while the instructions I found for new version suppression has avoided 100% CPU usage for "new release" pages, the donation URL changes below do not suppress the donation page:

app.donation.eoy.url = ''
app.donation.eoy.version = 10000
app.donation.eoy.version.viewed = 10000

I got a 100% CPU usage in headless mode today from the donation page. Seems Toby Pilling [:tobyp] was wrong that ESR 140 might fix this problem.

Is there a config change that suppresses the donation page, or a way for headless not to go into 100% CPU usage when it is displayed?

Comment 7

[Wayne Mery (:wsmwk)]

Florian, how might we profile this issue?
I don't see headless mentioned at https://profiler.firefox.com/docs/#/./guide-startup-shutdown

Or, is there a smarter way to approach this?

Comment 8

[Florian Quèze [:florian]]

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

Florian, how might we profile this issue?
I don't see headless mentioned at https://profiler.firefox.com/docs/#/./guide-startup-shutdown

I think you should still be able to use startup + shutdown profiling in headless mode, as long as you can shutdown the process cleanly without killing it. An other option would be to stop the profiler using a signal.

Comment 9

[Toby Pilling [:tobyp]]

(In reply to Bruce Momjian from comment #6)

Is there a config change that suppresses the donation page, or a way for headless not to go into 100% CPU usage when it is displayed?

Hi Bruce, have you tried setting mail.inappnotifications.enabled to false?

Comment 10

[Bruce Momjian]

No, I have not tried that. and I don't see it documented anywhere. I will set it to false, but I am not sure how to test it since the donation page is not showing anymore. What I did this morning was to schedule to run this command with a file replacement script on every Thunderbird update, which should disable all notifications:

jq '.notifications.[].description |= "[DISABLED]"' /users/$USER/.thunderbird/*/scheduled-notifications/notifications.json

Comment 11

[Wayne Mery (:wsmwk)]

To force notifications, set mail.inappnotifications.bypass-filtering to true in Settings > Config Editor

Comment 12

[Bruce Momjian]

Okay, so I know that will cause 100% CPU in headless mode. I guess my question is whether that new config setting will always prevent donation/new_features tab. I might no know for another year. If you want me to test a new binary or new config setting with that setting, please let me know. FYI, headless is being run in a systemctl service..

Comment 13

[Wayne Mery (:wsmwk)]

A. Normally, each notification is 1. set to be time limited (calendar date) and 2. SHOULD appear once. mail.inappnotifications.bypass-filtering=true will bypass those two items. So if the notification exists on our servers (hasn't been deleted or disabled) then you should continually get that notification.

B. mail.inappnotifications.enabled=false should force notifications to not appear under any circumstances.

The current set of notifications is still active, so mail.inappnotifications.enabled=true with mail.inappnotifications.bypass-filtering=true should trigger your issue for until Dec 3 when the appeal expires.

Comment 14

[Wayne Mery (:wsmwk)]

Bruce are you still seeing high CPU?

Comment 15

[Bruce Momjian]

I empty the notifications.json every time Thunderbird is updated, so I no longer get any notifications, including in --headless, so I don't have 100% CPU anymore. I am currently running 140.12.0esr on Debian 13. Would you like me to test with the normal notifications.json file to see if I get 100% CPU?