106014 - Thread pane goes blank sometimes

Status: VERIFIED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[Ralph Hartley]

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).

Comment 1

[Dimitrios]

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)

Comment 2

[Ralph Hartley]

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.

Comment 3

[John Levon]

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...

Comment 4

[Ralph Hartley]

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.

Comment 5

[Ralph Hartley]

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.

Comment 6

[Ralph Hartley]

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.

Comment 7

[Boris 'pi' Piwinger]

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

Comment 8

[Ralph Hartley]

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.

Comment 9

[Boris 'pi' Piwinger]

Very strange, but probably Networking can say more -> REASSIGNing.

pi

Comment 10

[Boris 'pi' Piwinger]

Any news?

pi

Comment 11

[Boris 'pi' Piwinger]

No response in two months, hence closing the bug. If you can in a new version
again reproduce the problem, reopen.

pi

Comment 12

[Karen Huang]

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