User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 Build Identifier: Thunderbird 1.6a1 (20060116) [This may or may not be related to bug #272988. The description there isn't very clear] When clicking on any message in the message index pane, nothing is displayed at first. Any following click on another message in the message index will show the body of the message that has been clicked before: click on message a: nothing click on message b: body of message a click on message c: body of message b If protocol logging is enabled, it shows that the body of the correct message is fetched, it is just not correctly displayed. We are using IMAP with dovecot 1.0-stable as server, with "imap_client_workarounds = outlook-idle tb-negative-fetch". Thunderbird 1.0.7 (20050923) works fine, 1.5 (20051201) and 1.6a1 (20060116) both show the problem described. Reproducible: Always
Can you please attach the protocol log?
Created attachment 208735 [details] thunderbird protocol log This is the requested log. I've anonymized some addresses/names, but without changing string sizes. Two messages were requested by the user (by clicking on the message in the index panel), and the log indicates that both were fetched in the correct order and with the full body. However, the first was only displayed when clicking on the second one in the message index panel. The second was not displayed (following the observed pattern, it would have been displayed when clicking on a third message, but we exited thunderbird instead).
I should add that using 'tail -f' on the protocol logfile, we verified that the message body was fetched when clicking on the message in the index panel, i.e. we can definitely rule out that the first message body was fetched only when clicking on the second.
It seems that this bug is related to the way thunderbird sets up a profile. The bug occurs if one starts with a fresh profile, it happens if one uses a profile from thunderbird 1.0, but it does not happen if one imports settings from mozilla.
Confirmed same problem with dovecot / thunderbird 1.5 (and not 1.0)
Some more observations: A) comment #4 contains an incorrect statement. TB 1.5 does NOT work if importing settings from mozilla; the respective user just reverted to POP3 by an oversight. B) the following other IMAP clients work flawlessly: evolution 2.0.1, sylpheed 1.0.4, TB 1.0.7 (20050923), mutt 1.5.6i, and pine 4.61 C) the problem has been reproduced by multiple users at our site (i.e. nobody is able to use TB 1.5)
*** Bug 336233 has been marked as a duplicate of this bug. ***
*** Bug 333323 has been marked as a duplicate of this bug. ***
Just as an update. The bug seems to go away when you upgrade to Dovecot version 1.0 b7 or higher. I don't know exactly where it goes away, but I had the same situation until I upgraded my Dovecot server. The previous version I saw the same symptoms on was 1.0 stable 20050221 in RPM format (a nightly development build deemed stable, if I recall correctly).
The problem does not happen anymore with dovecot 1.0beta8, although it did occur with 1.0-stable (which is older despite the version name :-)
Which is not to say this is a bug in Dovecot, as far as I'm concerned. Dovecot has been known to work around various MUAs' peculiarities, and this just might be the consequence of another workaround being added. Thunderbird 1.5 has been around for some while, afterall.
I would agree with the statement that it isn't necessarily a bug in the applicable version of Dovecot. It almost seemed as if the message was getting loaded properly, but not being "finished" and committed into the Thunderbird buffer correctly, until the next message was loaded and the buffer was closed and restarted. Does that make any sense?
I remember seeing a comment that this would be related to the order of IMAP headers sent from Dovecot. If I remember correctly, Thunderbird expects them in certain order and Dovecot may send them in any order (since the order is not specified in the IMAP specification). Someone more familiar with IMAP might be able to confirm this.
that was the source of the original problem - I believe I fixed that problem. See bug 246966. Perhaps that fix didn't work for dovecot servers; I'm not sure.
version 3.0a1 (2008050715) works
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.