I don't know how to reproduce this consistantly, but I see it about once a week. I've never caught it happening when I was looking. I will look more carefully at it next time it happens. Looked at outstanding bugs with summaries containing "blank" or "thread pane" and didn't find a good match. Workaround: Close the mail window and open a new one. Nothing else I've tried works. Build ID: 2001101508 (but has been happening for quite a while).
Ralph, have you tried to create a new profile? Are you still seeing this bug with newer builds ? (in the past, there were some bugs like this one)
Recently I tried a new profile. No change. I am now also seeing this on a new instalation of BuildID 2001122106 (Mozilla 0.9.7) on Windows. My mail configuration uses two imap servers. The problem appears to happen while reading messages on one server when a new message arrives on the other. I don't know if this is a change, but to get the message list back it is enough to switch to another folder and back.
Ralph, you're making sure to remove any previous Mozilla installations before installing the new one right ? Does this still happen with a new build ? Thanks. I've never seen a problem like this...
Sometime in the last month or two this has stoped happening. It's hard to tell exactly when. Now it does go blank when it rereads the message headers (which it does when another client makes changes) but it reapears when it is done (so it's OK). It didn't before, so if I read my mail from home the one at work would be blank when I got back. I still have a version around somewhere that is newer than my last comment, but still has this behavior, but there is no point in looking for it now. I'm sure I didn't replace my profile during the time the fix happened, but I changed builds several times.
I'm afraid I spoke too soon. I just didn't trigger it for a while. I see it noe on build ID: 2202042309 Possible steps to reproduce: Install mozilla on Machine A. Configure imap mail account on server C. Install mozilla on Machine B. Configure imap mail account on server C. Open mail pane on Machine A, and click Inbox. Leave mail window open. Open mail pane on Machine B. Read mail and delete at least one message. Threadpane on machine A goes blank and stays blank. I will try this again with two *completely* fresh installations, and let you know how it goes.
I just reproduced this using the above perscription on to completely fresh installations of Mozilla 1.0 rc1 (Build ID: 2002041711) Machine A was linux and B was Windows Me. No changes from default peferences. The inbox contains over 1000 messages. The threadpane did not go blank immediately, it took 10-15 minutes. I can not rule out the posibility that incoming mail arrived during that time, I supect that it did. It was not neccessary to delete any messages on either machine. Just being there reading the same message (but possibly different on each) the whole time (with incomming messages?) was enough. BOTH threadpanes went blank, I did not notice this before because the machines were not in the same building (but the test machines are in the same room). I'm pretty sure I have never seen this happen when no more than one mail widow was open at a time.
So my understanding is that you are accessing the same IMAP account from two different machines at the same time, right? Then it is probably more a networking problem. I don't really know how IMAP is supposed to handle this. Can you elaborate on that? pi
Correct. One server, one account, one mailbox, two clients on different machines. It happens when I don't close the one at work and then check my mail from home (or vice versa). I just tried this with a different server, and got different results. On the alternate server (version 2000.283rh) this bug does not happen. Only one client is notified of new messages, but that may be acceptable behavior (and would be a different bug if not). On the server I normaly use (version 2000.277) it does. There are two possibilities: The server version (or configuration) has a bug. In that case it's not mozilla's fault and this bug is invalid. It might be worth fixing anyway if such servers were common, but apparently they are not. Or, the server is behaving in an unusual, but legal, way. In that case this bug is correct, though expressed rarely. It should be fixed, because the rare behavior (or other legal behavior) that triggers it could become common in the future. When I have time I will try to find out exactly what the sequence of events is (do you know of a good tool for gathering that sort of information?), and what the protocol document says about them.
Very strange, but probably Networking can say more -> REASSIGNing. pi
Any news? pi
No response in two months, hence closing the bug. If you can in a new version again reproduce the problem, reopen. pi
Verified WFM on all the platforms: Windows 08-23-10-1.0 branch build Linux 08-23-07-1.0 branch build Mac 08-23-05-1.0 branch build