Thunderbird Community Forum

My email is very slow since I moved it to my new Dell laptop, sending, reading new messages, deleting and moving, NOT old messages. It was also slow on my old tower PC, but not this slow. I might leave Thunderbird if this continues. Not worth my time. Thank you!

Hello everyone. Thanks for all your support.

A few weeks ago I started noticing a pop up window was occurring every (approx) 5 minutes in Thunderbird suggesting that I run a compact to save 992MB. I assumed this would stop happening after a few weeks and a few updates from Mozilla, but the problem has remained, so I'm coming here to ask about it.

Context: I'm on Windows 11. I have multiple email accounts that my Thunderbird reaches out to. At least one of the accounts is retired so reaching out to its historical server fails.

Reproducing: For me to reproduce it, I run the compact. Quit Thunderbird. Start Thunderbird. It reports 992MB can be freed. I let it compact. The main inbox disappears and reappears. I wait a few seconds and restart Thunderbird. It again tells me that it can save 992MB by running a compact.

What I've tried: I've tried repair on the inbox folder of the account I'm typically in. That didn't help. I have many other folders across many accounts and not tried to repair any other folders. I've searched the Mozilla help system.

Logs: It seems to me that a compact is probably failing but I don't know where to look for evidence of the failure.

Whenever I start Thunderbird, I get messages such as that some mailboxes cannot be compacted and some filtering cannot be done "because another operation is in progress". Why is this? How can I prevent it? It is a nuisance having to go and chase down and correct the filtering that has not taken place.

新規メールを作成して宛先を入力する時、メールアドレスを少し入力するだけで自動補完してくれるのですが その自動補完が入力から表示されるまで約10秒程度かかっている。

Thunderbirdバージョン149.0.1 「設定」≫「編集」≫「アドレス入力」の設定は以下の通り。 ☑ローカルのアドレス帳 ☐LDAPサーバー ☑メール送信時に受信者を次のアドレス帳に自動で追加する：記録用アドレス帳 アドレス帳の初期表示ディレクトリー：最後に使用したディレクトリー

メールアドレスを自動補完する際に、どういった検索をかけているのか。 同様の症状が出た方はいればどうやって解決したのか。

有識者の方々、ご教示ください。

Sometimes the index becomes too large, making searching very difficult. The solution is to reset the index, which involves deleting the global-messages-db.sqlite file. After Thunderbird rebuilds the index, searching is simpler and faster. Adding a menu or an automatic database reindexing process would be a significant improvement!

I have the following very frustrating symptoms:

1) Thunderbird will frequently decide that it does not have the headers for a particular folder, and will reload them. This is in spite of the fact that I had all the headers the last time that I used the program, and I have not restarted Thunderbird or the computer (although I may have put it to sleep). In one specific case, I clicked on my Inbox, and TB started a "compact" operation, and then it started to download *all* of the headers. Eventually it produced an error message for the compaction: " The folder ‘Inbox on williamatwood41@gmail.com’ could not be compacted because writing to folder failed. Verify that you have enough disk space, and that you have write privileges to the file system, then try again."

2) Thunderbird will often state that a summary file cannot be opened: "Unable to open the summary file for Drafts on william.atwood@concordia.ca. Perhaps there was an error on disk, or the full path is too long." I have seen this for the Drafts folder, for the Inbox folder, for the Sent folder, and for arbitrary folders that I had previously opened successfully.

3) One day, I clicked on a folder that contained 6116 messages. I saw it download all of the headers. Then the right panel declared "No message found."

The next day, I clicked on the same folder. While downloading the headers, TB listed the low-numbered messages on the right side (upper panel), and then switched to the most recent message once all the headers had been downloaded. So, the behavior changed from one day to the next.

All of this seems to have started when I placed a restriction on the length of time that messages are synchronized. This was done because I was running out of disk space on my 250 GB disk. I subsequently replaced this disk with a 500 GB disk, but have not (yet) relaxed the constraint, because I wanted to get to the bottom of the problem.

My best guess is that setting the disk space limit has triggered some misuse of a pointer, which is resulting in the garbage-in, garbage-out syndrome. However, I could be way off.

I would be very happy to work with anyone on the TB team, and invoke whatever debugging tools are necessary (under direction) to find the root cause of this error.

I HATE this new mail program. It takes forever to load on my computer and is VERY slow. Is there any way to get the old program back? I am 83 years old and find this version very difficult to use. I had the older version for years (more than I can remember) and it was very easy to use. Is there a way for me to get an easier program -- like the old one. Please help me

It is my custom to run spell check after typing an email. Today, sudenly, the write window hangs when I click on spelling. Does not happen in troubleshoot mode. I have no extensions installed and default theme. I did try disabling hardware acceleraton, but did not help.

Yesterday all workd OK, and thre have been no changes to the computer snce.

Title: CardBook 104.7 folder pane frozen ~40 minutes at every startup - TB 140.8.1 ESR - Linux Mint 22.3

Environment: - Thunderbird: 140.8.1 ESR 64-bit - CardBook addon: 104.7 - OS: Linux Mint 22.3 Cinnamon 64-bit - Fresh install of both Thunderbird and CardBook - 3 Gmail IMAP accounts - 5 CardBook address books, all local FILE type (.vcf files in /home/nesko/cardbook/), no CardDAV or remote server involved. Largest address book has approximately 1500 contacts.

Symptom: At every cold startup, the CardBook folder pane (address book list) is completely frozen and unresponsive for approximately 40 minutes. Thunderbird itself starts quickly and all email accounts and other addons function correctly. Only the CardBook folder pane is affected. After approximately 40 minutes CardBook becomes responsive without any user intervention.

Error console output at startup consistently shows: - TypeError: can't access property "addEventListener", currentWindow is null (implementation.js:28:13) - TypeError: can't access property "document", currentWindow is null (implementation.js:567:15) - CardBookXULNotifyListener.js:599:13 - Content process is not responsive while sending DevToolsProcessParent:watchTargets

Additional observations: - On one startup, 8 duplicate CardBook tabs appeared simultaneously when TB's content process finally became responsive, suggesting CardBook was retrying initialization multiple times while waiting for TB's window - Running TB in Troubleshoot Mode (all addons disabled) confirms TB itself is healthy and starts quickly - The errors reference CardBook's own initialization code (CardBookXULNotifyListener.js) attempting to access Thunderbird's window (currentWindow) before it is fully ready - TB's content process unresponsive message appears during the same startup window

Steps taken so far: - Unchecked "Keep messages in all folders" in Synchronization & Storage for all 3 IMAP accounts — this improved overall TB startup time - Unchecked "Run synchronization at Thunderbird startup" in CardBook Preferences → Sync — this reduced the CardBook freeze from over 1 hour to approximately 40 minutes - Reported to CardBook developer at cardbook.thunderbird@gmail.com

Question for TB support: Is there a known issue with TB 140 ESR's content process initialization timing that could cause addons to fire before TB's window is fully ready? The currentWindow is null errors suggest CardBook is initializing at a point where TB's window object does not yet exist. Is there a TB-side fix or workaround for this timing issue?

Hi. I access a gmail account via Thunderbird. It's generally quite efficient, but recently it has become very sluggish. I have pretty fast internet, wired at 1G, so usually my mail appears almost immediately. In the last week or so it has slowed down dramatically, sometimes requiring multiple login attempts. Any idea what's going on? Thanks. Steve

I have used Thunderbird for many years and and have loved it. However, recently my "Local Folders Inbox" have been extremely slow (deleting emails, reviewing an email, etc.). I have tried every suggestion that I have found without any change: reducing emails in the folder (down to about 75 remaining), compacting and repairing the folder, deleting and rebuilding all of the msf files and global database, disabling all addons, empty trash and junk, clear the cache, disable hardware acceleration, exclusion in antivirus, etc. It has become very frustrating. Any suggestions would be greatly appreciated.

I posted this question some time back but didn't receive any helpful answers and don't know where my post is. In the upper right-hand corner there is suppose to be 3 symbols. One to lower the app, one to make the app full screen or partial and one with an X. I have jumbled symbols where the 3 good ones are. It does it in trouble shoot mode. I tried disabling addons but I can't get the normal symbols back. Here's what it looks like... Thank you for any help.

My TB 147.0.2 Release channel is using excessive amounts of memory. Below is the memory usage data.

Previously I was on the ESR channel for many years. Also I originally used the Lightning calendar plug.

What I'm seeing is that when TB starts the memory usage is high. If I check at another time on the same day it is sometimes only around 250-350MB.

I've tried suggest options like reducing data in Local Folders (on a separate data drive) but to no avail. As I type now TB memory usage is now only 286.4MB. However rest assured in a while this will jump back to over 3GB and it has an is now 3,151.4MB.

I don't see this on another 2 PCs. One is setup with Locals Folders and the other is just the mail Inbox and sub folders. The only other difference is that the PC with this TB installation also has one Newsgroup server configured.

There surely has to be a bug somewhere causing these excessive memory usages.

Main Process (pid 13380) Explicit Allocations

3,313,474,259 B (100.0%) -- explicit ├──3,179,427,220 B (95.95%) ── heap-unclassified ├─────38,393,176 B (01.16%) ++ window-objects ├─────38,283,520 B (01.16%) ++ js-non-window ├─────23,911,654 B (00.72%) ++ startup-cache ├─────11,605,760 B (00.35%) ++ storage ├──────5,005,920 B (00.15%) ++ images ├──────4,031,040 B (00.12%) ++ threads ├──────2,866,272 B (00.09%) ++ layout ├──────2,273,616 B (00.07%) ++ script-preloader ├──────1,422,800 B (00.04%) ── icu ├──────1,083,184 B (00.03%) ++ xpconnect ├────────917,568 B (00.03%) ++ dom ├────────704,416 B (00.02%) ++ atoms ├────────627,133 B (00.02%) ++ preferences ├────────546,544 B (00.02%) ++ gfx ├────────360,720 B (00.01%) ++ cycle-collector ├────────328,720 B (00.01%) ++ telemetry ├────────318,528 B (00.01%) ++ phc ├────────312,608 B (00.01%) ++ fog ├────────305,312 B (00.01%) ++ url-preloader ├────────212,528 B (00.01%) ++ network ├────────212,480 B (00.01%) ++ string-bundles ├────────166,128 B (00.01%) ++ data-storage ├─────────80,048 B (00.00%) ── profiler/profiler-state ├─────────42,356 B (00.00%) ── skia-font-cache ├─────────19,024 B (00.00%) ++ xpcom ├─────────10,064 B (00.00%) ── memory-reporter-manager ├──────────3,312 B (00.00%) ── xul-prototype-cache/other ├──────────1,904 B (00.00%) ── cookie-service ├────────────624 B (00.00%) ── history-links-hashtable ├─────────────80 B (00.00%) ── cert-storage/storage ├──────────────0 B (00.00%) ── maildb/database(UNKNOWN-FOLDER) ├──────────────0 B (00.00%) ── media/libogg ├──────────────0 B (00.00%) ── spell-check └──────────────0 B (00.00%) ++ webgl

Other Measurements

140,737,488,289,792 B (100.0%) -- address-space ├──138,527,509,839,872 B (98.43%) ── free(segments=402) ├────2,206,026,694,656 B (01.57%) ++ reserved └────────3,951,755,264 B (00.00%) ++ commit

273,510,400 B (100.0%) -- decommitted ├──269,578,240 B (98.56%) -- heap │ ├──268,451,840 B (98.15%) ── decommitted │ └────1,126,400 B (00.41%) ++ unused-pages └────3,932,160 B (01.44%) ── js-non-window/gc-heap/decommitted-pages

5,245 (100.0%) -- event-counts └──5,245 (100.0%) ++ window-objects

1 (100.0%) -- extensions └──1 (100.0%) ── Extension(id=default-theme@mozilla.org, name="System theme — auto", baseURL=moz-extension://d69e3532-324c-43f3-959c-7bc3f6aad1c5/)

3,580,661,760 B (100.0%) -- heap ├──3,311,083,520 B (92.47%) -- committed │ ├──3,272,606,352 B (91.40%) ── allocated │ ├─────28,273,376 B (00.79%) ── bookkeeping │ ├──────8,202,000 B (00.23%) ++ bin-unused │ ├──────1,785,856 B (00.05%) ── unused-pages/dirty │ └────────215,936 B (00.01%) ── waste └────269,578,240 B (07.53%) ++ decommitted

4,942,128 B (100.0%) -- images └──4,942,128 B (100.0%) -- content

  ├──4,934,128 B (99.84%) ++ vector
  └──────8,000 B (00.16%) ++ raster/used

19 (100.0%) -- ipc-channels ├───3 (15.79%) ── PBackgroundParent ├───3 (15.79%) ── PProfilerParent ├───1 (05.26%) ── PAPZInputBridgeChild ├───1 (05.26%) ── PBackgroundStarterParent ├───1 (05.26%) ── PCanvasManagerChild ├───1 (05.26%) ── PCompositorManagerChild ├───1 (05.26%) ── PContentParent ├───1 (05.26%) ── PGPUChild ├───1 (05.26%) ── PImageBridgeChild ├───1 (05.26%) ── PProcessHangMonitorParent ├───1 (05.26%) ── PRDDChild ├───1 (05.26%) ── PRemoteWorkerDebuggerManagerParent ├───1 (05.26%) ── PRemoteWorkerServiceParent ├───1 (05.26%) ── PVRManagerChild └───1 (05.26%) ── PVsyncBridgeChild

20 (100.0%) -- ipc-channels-peak ├───3 (15.00%) ── PBackgroundParent ├───3 (15.00%) ── PProfilerParent ├───2 (10.00%) ── PAPZInputBridgeChild ├───1 (05.00%) ── PBackgroundStarterParent ├───1 (05.00%) ── PCanvasManagerChild ├───1 (05.00%) ── PCompositorManagerChild ├───1 (05.00%) ── PContentParent ├───1 (05.00%) ── PGPUChild ├───1 (05.00%) ── PImageBridgeChild ├───1 (05.00%) ── PProcessHangMonitorParent ├───1 (05.00%) ── PRDDChild ├───1 (05.00%) ── PRemoteWorkerDebuggerManagerParent ├───1 (05.00%) ── PRemoteWorkerServiceParent ├───1 (05.00%) ── PVRManagerChild └───1 (05.00%) ── PVsyncBridgeChild

8 (100.0%) -- js-helper-threads ├──8 (100.0%) ── idle └──0 (00.00%) ── active

47,463,752 B (100.0%) -- js-main-runtime ├──17,759,904 B (37.42%) ++ realms ├──16,789,232 B (35.37%) ++ zones ├──11,440,056 B (24.10%) ── runtime └───1,474,560 B (03.11%) ++ gc-heap

11,691,152 B (100.0%) -- js-main-runtime-gc-buffers ├──11,270,624 B (96.40%) ── used ├─────218,656 B (01.87%) ── free └─────201,872 B (01.73%) ── admin

24,379,392 B (100.0%) -- js-main-runtime-gc-heap-committed ├──20,174,072 B (82.75%) ++ used └───4,205,320 B (17.25%) ++ unused

20 (100.0%) -- js-main-runtime-realms ├──13 (65.00%) ++ system └───7 (35.00%) ++ user

21 (100.0%) -- message-manager └──21 (100.0%) -- referent

  ├──10 (47.62%) -- child-process-manager
  │  ├──10 (47.62%) ── strong
  │  └───0 (00.00%) -- weak
  │      ├──0 (00.00%) ── alive
  │      └──0 (00.00%) ── dead
  ├───6 (28.57%) -- parent-process-manager
  │   ├──6 (28.57%) ── strong
  │   └──0 (00.00%) -- weak
  │      ├──0 (00.00%) ── alive
  │      └──0 (00.00%) ── dead
  └───5 (23.81%) -- global-manager
      ├──5 (23.81%) ── strong
      └──0 (00.00%) -- weak
         ├──0 (00.00%) ── alive
         └──0 (00.00%) ── dead

1,924 (100.0%) -- observer-service └──1,924 (100.0%) ++ referent

868 (100.0%) -- observer-service-suspect ├──437 (50.35%) ── referent(topic=xpcom-shutdown) ├──225 (25.92%) ── referent(topic=memory-pressure) └──206 (23.73%) ── referent(topic=last-pb-context-exited)

363 (100.0%) -- preference-service └──363 (100.0%) ++ referent

0 (100.0%) -- queued-ipc-messages └──0 (100.0%) ── content-parent(Browser, pid=2140, open channel, 0x228780fb828, refcnt=35)

147,366 B (100.0%) -- shared-string-bundles ├───65,420 B (44.39%) ── SharedStringBundle(url="chrome://global/locale/dom/dom.properties", shared=true, refCount=2, sharedMemorySize=65420) ├───24,560 B (16.67%) ── SharedStringBundle(url="chrome://global/locale/layout/htmlparser.properties", shared=true, refCount=2, sharedMemorySize=24560) ├───22,528 B (15.29%) ── SharedStringBundle(url="chrome://global/locale/security/security.properties", shared=true, refCount=2, sharedMemorySize=22528) ├───11,830 B (08.03%) ── SharedStringBundle(url="chrome://necko/locale/necko.properties", shared=true, refCount=2, sharedMemorySize=11830) ├────7,420 B (05.04%) ── SharedStringBundle(url="chrome://global/locale/css.properties", shared=true, refCount=2, sharedMemorySize=7420) ├────6,190 B (04.20%) ── SharedStringBundle(url="chrome://global/locale/layout_errors.properties", shared=true, refCount=2, sharedMemorySize=6190) ├────2,756 B (01.87%) ── SharedStringBundle(url="chrome://global/locale/commonDialogs.properties", shared=true, refCount=2, sharedMemorySize=2756) ├────2,358 B (01.60%) ── SharedStringBundle(url="chrome://global/locale/printing.properties", shared=true, refCount=2, sharedMemorySize=2358) ├────2,174 B (01.48%) ── SharedStringBundle(url="chrome://global/locale/layout/HtmlForm.properties", shared=true, refCount=2, sharedMemorySize=2174) ├────1,488 B (01.01%) ── SharedStringBundle(url="chrome://global/locale/mathml/mathml.properties", shared=true, refCount=2, sharedMemorySize=1488) ├──────246 B (00.17%) ── SharedStringBundle(url="chrome://branding/locale/brand.properties", shared=true, refCount=2, sharedMemorySize=246) ├──────226 B (00.15%) ── SharedStringBundle(url="chrome://global/locale/xul.properties", shared=true, refCount=2, sharedMemorySize=226) └──────170 B (00.12%) ── SharedStringBundle(url="chrome://global/locale/svg/svg.properties", shared=true, refCount=2, sharedMemorySize=170)

28,598,376 B (100.0%) -- window-objects ├──16,114,528 B (56.35%) ++ dom ├──12,432,968 B (43.47%) ++ layout └──────50,880 B (00.18%) ── property-tables

          262,144 B ── font-list-shmem
                0 B ── gfx-textures
                0 B ── gfx-textures-peak
                0 B ── gfx-tiles-waste
                  0 ── ghost-windows
                0 B ── gpu-committed
                0 B ── gpu-dedicated
                0 B ── gpu-shared
    3,272,606,352 B ── heap-allocated
        1,048,576 B ── heap-chunksize
                  0 ── imagelib-surface-cache-already-present-count
          304,880 B ── imagelib-surface-cache-estimated-locked
          314,928 B ── imagelib-surface-cache-estimated-total
                 85 ── imagelib-surface-cache-image-count
                 52 ── imagelib-surface-cache-image-surface-count
                 85 ── imagelib-surface-cache-locked-image-count
                 45 ── imagelib-surface-cache-locked-surfaces-count
                  0 ── imagelib-surface-cache-overflow-count
                  0 ── imagelib-surface-cache-table-failure-count
                  7 ── imagelib-surface-cache-tracked-cost-count
                  7 ── imagelib-surface-cache-tracked-expiry-count
                  0 ── imagelib-surface-cache-tracking-failure-count
          454,656 B ── js-main-runtime-temporary-peak
                  8 ── js-main-runtime-zone-count
    3,386,552,320 B ── private
    3,497,312,256 B ── resident
    3,369,873,408 B ── resident-unique
       29,638,345 B ── shmem-allocated
        2,612,339 B ── shmem-mapped
        6,256,466 B ── system-heap-allocated
2,209,978,449,920 B ── vsize

70,172,792,717,312 B ── vsize-max-contiguous

                0 B ── wasm-runtime
                  0 ── webgl-buffer-count
                0 B ── webgl-buffer-memory
                  0 ── webgl-context-count
                  0 ── webgl-renderbuffer-count
                0 B ── webgl-renderbuffer-memory
                  0 ── webgl-shader-count
                  0 ── webgl-texture-count
                0 B ── webgl-texture-memory

End of Main Process (pid 13380)

Thunderbird used to easy and quick to use - now it is slow and cumbersome. For instance, to get it to send an email there is a delay now. It just seems to be freezing up. Lynn

Hi, I’ve been using Thunderbird, but after installation it’s taking up 128GB of disk space. That seems unusually large — could you please help check what might be causing this?