steps: 1. Launch mail and select a msg (note that it launches with default window size) 2. Maximize the Mail window to cover display in entire screen. You will note that thread pane displays garbage (or it kinda overlaps thread pane info and the hearder info) Build and platform: 2000-06-21-09-M17, windows commercial build.

Can you fix this by resizing the window?

This can be fixed by 1. Minimizing and maximizing again. (sometimes do this couple of times) 2. Scrolling tgh messages.

are you still seeing this? I've tried this multiple times on my NT commercial build from 6/25 and haven't been able to reproduce this regardless of the size I start my mail window off as.

I still see this on 2000-06-26-09-M17 windows commercial build on NT 4.0.

Are you still seeing this? I should just look at this on your machine. I can't reproduce this on my commercial build from 7/5.

reassigning to hyatt. It sounds like either a tree bug or a painting bug.

I still see this bug on today's commercial build (2000-07-06-09-M17).

I don't see this using M18 verification build on Win98.

I can see this on either 08/02 verif build, or an up-to-date debug build on win2k -- the key thing to reproducing this is to scroll the thread pane all the way to the bottom (scrolling almost to the bottom is not enough). When the window resizes, what I see is the original paint locations of the right-hand threadpane scrollbar, and the splitter, are left on screen (not repainted); also a ~3 of what should be tree rows at the top of the threadpane are blank, and do not respond to mouseclick. (I also see these "dead" rows, but not the visual cruft on linux and mac). However, anything that triggers a reflow recovers the threadPane to a normal state.

nsbeta3+

*** Bug 45801 has been marked as a duplicate of this bug. ***

Mass-accepting.

P2

*** Bug 51238 has been marked as a duplicate of this bug. ***

Last dup includes crash, ->critical, P1, crash keyword.

Have a simple test case to reproduce this (See above): 1) Open in xul 2) scroll to bottom 3) maximize 4) try to scroll. CRASH!

PDT agrees P1 if it crashes, but P2 if it's just repainting problems.

I FIXED IT! I FIXED IT! I'VE BEEN WORKING ON THIS BUG FOR OVER 12 HOURS NOW, AND I FINALLY FIXED IT! YES! YES! YES!

Wonderful hyatt! Suresh - can you verify?

Tested using today's commercial build on Win NT. Tested using my original steps and also using evaughan testcase. Marking Verified.

This has returned (one bit of badness in what has been a big improvement in tree stability). My comments in this bug 08/03 pretty much describe what I see on windows. Linux seems to be OK; checking Mac.

Really reopening.

Eric's test case shows no flaws and no crash. The threadPane does get cosmetically corrupted, but I haven't found a way to crash it. As soon as you cause scrolling to occur, the threadPane returns to normal. (win2k).

rtm-/future, assuming the cosmetic corruption is the same as I'm seeing on Win98.

*** Bug 65064 has been marked as a duplicate of this bug. ***

Hyatt: I haven't seen this bug since we've landed. I checked today (I normally have all my builds on each platform set to persist maximized state.) Builds 2001032904 on Windows 2000, build 2001033004 on Mac OS 9.1 and build 2001032908 on Linux (Mandrake 7.2 with KDE 2) all maximizied fine to me. If you mark it FIXED, I can VERIFY. Thanks.

Fixed.

gone.