Closed Bug 529210 Opened 10 years ago Closed 9 years ago
Printing of messages with attachments from non-synchronized IMAP folder stalls (cache enabled, MIME parts on demand)
If a previously non-cached and non-synchronized message is tried to be printed from an IMAP folder, and it contains an attachment which cannot be displayed inline, the dialog Title: (Loading content for Printing) Progress: Preparing ... with the "Cancel" button disabled and the status bar showing "Loading message to print", no network activity. The dialog can be canceled using the [x] on the title bar. When revisiting the message later, it may print, assuming that the content is cached by then. Steps to reproduce: 1) disable offline synchronization; 2) verify that cache is active, clear cache, restart; 3) select a message with a PDF or DOC attachment; 4) use toolbar button or Ctrl+P to start printing; 5) observe the notification, no print dialog appears; 6) close notification with titlebar button, no printing. Workaround: 1) set browser.cache.disk.enable to false (still won't print); 2) set browser.cache.memory.enable to false as well; 3) restart and go to the same message; 4) use toolbar button or Ctrl+P to start printing; 5) observe the notification showing up briefly; 6) print dialog appears, proceed with printing. Thus, apparently a problem exists when caching the message first viewed, the attachment not being expanded or properly noticed. When printing in the second step, the message body is taken from the cache, but the existence of an uncached attachment causes the process to stall. Reproduced with Thunderbird 3.0RC1 build 1 on Windows, also with SeaMonkey 2.0 on Linux and Windows. Tested with two different IMAP servers, including Gmail.
These are the relevant sections of the IMAP log while the problem was seen. - Previously uncached and not synchronized message, cache enabled; - has a single PDF attachment, reproducible with small or large sizes; - message was sent with inline disposition, "attachment" won't work either; - IDLE was disabled to keep the log clean, doesn't make a difference. As another workaround, View > Message Source and waiting until the attachment source is loaded will allow subsequent printing of the message.
Nominating. I realize that the focus for IMAP is on synchronization to be used by default, but this is a highly visible bug for those users who decide to opt out of autosync during the migration dialog, or to limit offline copies by age. The workarounds are hard to figure out for a user without advanced knowledge.
Are you sure this is a regression from 2.0?
Yes, the same message opens the print dialog almost immediately when using TB 184.108.40.206 with memory cache enabled and no offline synchronization used.
Not blocking on this as this isn't the default use case and it doesn't seem to be something that will be hit by many users
Flags: blocking-thunderbird3? → blocking-thunderbird3-
Amazingly, this has been around in 3.0a1 (2008-05-07) already. I've tried to identify the regression window, and that's as early as I could get with the releases. Thus, no recent checkin caused this. Guess I never had the case of printing a message with attachment until I started using a production profile.
Related observations with those uncached and non-synchronized messages: - When opening, "Downloading messages..." sometimes stays in the status bar, the "busy" bar keeps spinning until a different message is selected; no other effects are observed. - Using "Mark as deleted" model, deleting such a message without previously opening the attachment, then expunging the folder may not permanently remove it, though other messages are deleted in the same step; a second expunge will succeed deleting that message (using "Compact" from the context menu). Guess: This somehow would suggest that the completion of reading a message is not correctly recognized, thus it stays in a status where more data is expected and the actually intended operation never gets invoked.
Per bug 533144 comment #3, setting mail.server.default.mime_parts_on_demand to false seems to serve as a workaround. The whole message is downloaded, and the print dialog opens correctly after the download completes without stalling. I yet have to check if this also avoids the other issues mentioned in comment #7.
Whiteboard: [workaround: comment #8]
After running some time with the preference enabled, I didn't see the issues described in comment #7 again. While this is good news for a workaround, it implies that there is some error when caching MIME parts on demands rather than caching the full message (adjusted summary to narrow down this bug's scope).
Summary: Printing of messages with attachments from non-synchronized IMAP folder stalls with cache enabled → Printing of messages with attachments from non-synchronized IMAP folder stalls (cache enabled, MIME parts on demand)
Ran into this bug as well on Thunderbird 3.0.4. Message synchronization has been disabled because I have a ton of messages on the server and space is limited on the laptop's SSD.
Given that the Migration Assistant of TB 3.1.x does no longer default to synchronization of accounts which haven't been synchronized in 2.0, this apparently gains visibility in current releases now. I'm renominating this to get at least on the wanted list to keep it on the radar. As said, it indicates a potentially more serious conflict between caching and downloading MIME parts on demand that should be looked at.
This /may/ have been fixed by bug 565852, needs testing to verify...
Ok, no longer an issue with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101123 Thunderbird/3.3a2pre, mail.server.default.mime_parts_on_demand was true but I disabled the disk cache due to bug 531033. (In reply to comment #7) > - When opening, "Downloading messages..." sometimes stays in the status bar, > the "busy" bar keeps spinning until a different message is selected; no > other effects are observed. This was independently reported as bug 599830 and duped to bug 565852; so, for what I can tell, the problem described here was fixed on trunk by that patch.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 565852
You need to log in before you can comment on or make changes to this bug.