Deleting unread messages makes tree view blank




17 years ago
9 years ago


(Reporter: Heikki Toivonen (remove -bugzilla when emailing directly), Assigned: David Hyatt)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: relnote-user)

Commercial release (branch) build 2000-10-31-14.

I have mails sorted so that latest is at the bottom. When I click on an unread
message somewhere in the middle, and shift+click on some other message below
that (so that I select a bunch of unread messages) and then press Delete key to
delete these, the whole tree view (messages listed by subject etc.) becomes blank.

This does not happen all the time, but most of the time. I have not yet figured
out a 100% reproduceable scenario.

I think I can still move between messages by using arrow keys (not sure about
this, though). I must move to another folder and then back to be able to see the
messages again in the folder where I deleted these messages.

Before hyatt's checkin on Monday night I did not get a blank tree, but it
usually became so horked it was unusable anyway. And scrolling the tree made it
blank. A while back this also resulted in crash if I scrolled, but I haven't
seen a crash in a few weeks. So this got perhaps a bit worse, but I think the
gain is better, and there is a simple workaround (look at other folder).
This must be a relnote. Something like:

Sometimes when you delete mail or news messages the message list becomes blank
even though there are messages left. You must view a different folder before you
can see messages in this folder again, or you can close the mail/news window and
reopen it to work around this problem.
Keywords: relnote
Whiteboard: relnote-user
I have not seen this happen if I delete read messages.

Comment 3

17 years ago
-> for release note on mailnews threadPane (although I 
imagine she may have something like this already slotted up). Give it back
to me when RTM has passed, as a tree bug. 

FWIW, I spent a while, and various combinations, trying to get this to happen
and I couldn't get it to occur. Any hints on how to do it: additional possible 
variables include whether in threaded mode or not, number of visible rows, 
total number of messages in folder, width/height of mailnews and threadPane 
(approx.). [Sorry for being tedious; just want to get a way to reproduce this, 
so we can look for a fix]. 
QA Contact: jrgm → esther
i don't think i've seen anything like this in quite awhile either
I will let you know if/when I see this again and what the exact conditions were.

But here is something to begin with... I have subscribed to XML-DEV, I get
something like 40 messages per night. I have filter to automatically move them
to XML-DEV folder. I have flat view on mails. I have about 50 read mails in the
XML-DEV folder, which means it is about 2-3 "screenfulls" of messages. I have
sorting by date, last come is at the bottom.

I have not seen this bug since I filed this bug, even though I am using the same
build. But normally I have the mail window open several days in a row, this week
I have restarted several times a day to do testing.
Hmm, now this is happening again. Or actually slightly different scenario.

In my INBOX I had received 8 unread messages (about 100 read). When I selected
INBOX it scrolled me automatically to where the first unread was visible. I
clicked on the first unread in the treeview with the mouse, read message,
pressed Delete. Funky stuff followed:

The message was deleted (empty row appeared).
The selection moved one line down to the next unread.
The all visible rows (inluding the empty row) seemed to move one line down.
Empty row appeared at the top.

Pressing Delete again deleted the selected message, left an empty row, move
everything down one row, empty row appeared at top. After a couple of more
Delete key presses the tree view was blank. Pressing Delete still deleted
messages and I was able to read the newly selected message in the message
window. The Mail Folders window did not update (it was saying 8 unread all the

I then changed to XML-DEV folder, which had one unread message. It automatically
scrolled to down to that message. I selected it, and Deleted it, and the same
thing happened. I continued deleting read messages and after a while I got a
blank tree view.


17 years ago
QA Contact: esther → laurel


17 years ago
OS: Windows NT → All
Hardware: PC → All

Comment 7

17 years ago
I think I am seeing this in this week's Mac builds.MTrunk 2000122010.
If I select an unread message and then hit Delete  while the message is loading,
the message content does not displayed all right and the next message gets
highlighted and its content displayed.  At that point, the previous deleted
message title is either visible and still selected or the line is blank.  Either
way when I scroll the thread pane, it goes entirely blank and need resizing the
window to get the display back.

Comment 8

17 years ago
Laurel, could you please check for a reproducible case here?

Comment 9

17 years ago
A while back I could reproduce this easily on Win98 or Mac ... now I cannot. It
used to be when you moved any message (single or multiple selection) from top or
a few messages down in the thread pane, a hole was created in thread list or
maybe the message(s) just moved/deleted would still appear in the thread list
until you forced a refresh.

I'm not able to reproduce that today on any of the platforms, commercial trunk
build dec 28.

I believe there are other duplicates about the same condition.


17 years ago
QA Contact: laurel → sheelar

Comment 10

17 years ago
wontfix for the tree in threadPane (outliner bab-ee!)
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
Huh? Wontfix seems like a wrong resolution... This might have fixed itself along
the way, so it could be worksforme. The code will be different when the outliner
lands, but this bug might still manifest itself there!

Comment 12

17 years ago
I see your point, Heikki (and that was me typing 'bab-ee!' above :-]), but
hyatt has/had a slew of threadPane bugs based on the old tree. Mailnews is
moving to the outliner, and it would be better to file new bugs on that widget
should/when problems are noted there, rather than try to repurpose a pile of
tree bug reports into outliner bugs.

As for wontfix, it is the case that multi-column uses of <tree> will not be 
actively supported. Apps will need to move to outliner if they can't live with 
their current problems with <tree>.
Yes, please do file any new outliner bugs you see in mail/news (mail window
front end), but as for this specific-to-tree bug (of which various attempts to
reproduce with various levels of success were achieved) it is gone.


9 years ago
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: sheelar → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.