Closed Bug 43326 Opened 24 years ago Closed 23 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 → 23 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: