Closed Bug 43326 Opened 24 years ago Closed 24 years ago

Thread Pane is corrupted while maximizing Mail window

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: skasinathan, Assigned: hyatt)

References

Details

(Keywords: crash, Whiteboard: [nsbeta3+][PDTP1][rtm-])

Attachments

(1 file)

test case
991 bytes, text/plain
Details
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.
Target Milestone: --- → M18
reassigning to hyatt. It sounds like either a tree bug or a painting bug.
Assignee: putterman → hyatt
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+
Keywords: nsbeta3
Whiteboard: [nsbeta3+]
Keywords: mailtrack
*** Bug 45801 has been marked as a duplicate of this bug. ***
Mass-accepting.
Status: NEW → ASSIGNED
P2
Priority: P3 → P2
*** Bug 51238 has been marked as a duplicate of this bug. ***
Last dup includes crash, ->critical, P1, crash keyword.
Severity: normal → critical
Keywords: crash
Priority: P2 → P1
Attached file test case —
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.
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP1]
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!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
QA Contact: lchiang → suresh
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.
Keywords: rtm
Really reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.
Whiteboard: [nsbeta3+][PDTP1] → [nsbeta3+][PDTP1][rtm-]
Target Milestone: M18 → Future
*** Bug 65064 has been marked as a duplicate of this bug. ***
QA Contact: suresh → stephend
Keywords: mailtrack
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.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
gone.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: