544748 - Hang on printing HTML message with attachment, when not fully downloaded from IMAP server

Status: RESOLVED DUPLICATE of bug 529210

(Thunderbird :: General, defect)

Description

[Philippp]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1

Thunderbird settings:
Do NOT store messages locally; download only messages smaller than 50kB;
using message preview pane.
Messages on an IMAP server.
In the message list, choose a message that is HTML and has an attachment, and whose size is over the download limit.
Chosse "print" -> the print dialog hangs. Closing TB does close the app window, but thunderbird.exe remains in the task manager! After starting TB again, it behaves strangely due to the process that is still waiting for something int he background - f.i. it hinders update of awailable IMAP folders.

Reproducible: Always

Steps to Reproduce:
1. Create new IMAP account
2. Under synchronization, set download files offline: NO
3. Set "only download messages smaller than 50kB"
4. In the menu, view: set "display attachments inline" to OFF
5. Re-start TB.
6. Receive an email that is HTML, has an attachment, and is larger than 50kB.
7. Click in the new mail, it will show corectly in the preview pane.
8. Right-click on the message, and chosse "print"
Actual Results:  
The print dialog opens, but remains at "Preparing...". Cancel button is grayed. You can close the dialog by the X-button, which SEEMS to cancel anything. In fact, a background process stays alive, and blocks some activity. For instance, TB does not discover any new IMAP subfolders in the tree.


Expected Results:  
The print dialog of the operating system should appear.

When closing TB after the problem has occurred, thunderbird.exe stays in the taskmanager (and TB does not write the prefs file). If you start Thunderbird, the still-running background process keeps blocking some activities (like discovery of IMAP folders). Very misleading, because nowmally a re-start would cure such hangs. Besides, any pref settings from the last session are lost!

Comment 1

[Philippp]

Attachment: Sample email that triggers the problem

Comment 2

[Philippp]

Attachment: Hanging print dialog

Comment 3

[Philippp]

Attachment: IMAP log (according to steps to reproduce)

Comment 4

[Philippp]

No significant CPU load in any stage of the problem.

Comment 5

[Philippp]

Attachment: prefs file

Comment 6

[rsx11m]

Does the problem persist if you set mail.server.default.mime_parts_on_demand
to false? If not, that might be another manifestation of the caching issue described in bug 529210 (plus the download limit and the incomplete shutdown).

Comment 7

[Philippp]

The problem seems to be solved with mail.server.default.mime_parts_on_demand set to FALSE - so Ill take this as a workaround - thanks!!

Symptoms look very similar to 529210 - though, the incomplete shutdown might be either a new aspect or a new discovery...