27724 - UI: resize of window leaves task bar at bottom at old position

Status: VERIFIED WORKSFORME

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

Description

[(not reading, please use [e-mail] instead)]

I noticed this with messenger and the browser window, see below.

start up 5.0 in the browser
./mozilla http://www.yahoo.com
(grab on the bottom of the browser window, and you can make it taller, and it
works fine)

now open messenger
make the messenger window taller

the task bar on the bottom stays where it was, doesn't move to the bottom

go back to the browser window, making the browser window taller won't work
either

Comment 1

[(not reading, please use [e-mail] instead)]

ok, if I open messenger first, it works fine.

but as soon as I open a browser window (so I have both browser and messenger)

I get this problem.

not sure who owns this.

Comment 2

[Phil Peterson]

Reassign to trudelle. Nominate for beta1.

Comment 3

[Peter Trudelle]

How do you even see this?  Mail crashes on me immediately, today's comm opt 
build and yesterday's too.

Comment 4

[(not reading, please use [e-mail] instead)]

mail is working for me on linux.  at least it was when I pulled and built at 10
am. 

I wasn't seeing the crasher that others were seeing, not sure why.

Comment 5

[Peter Trudelle]

Okay, got past the crash in the respins, but I'm not seeing anything that sounds
like this.  Are you only seeing it in your debug build?  Could you try a
verification build?  Is anyone else seeing this?

Comment 6

[daver]

Lisa, can you test this to make sure it's happening?

Comment 7

[Peter Trudelle]

I just did a debug build on Linux, and now I can see a long (2-3 second) delay

in relocation of the status bar to the bottom of the Messenger window after

resizing, but I don't see what was described.  I hardly think that would need to

be fixed for beta. Navigator window relocates status bar within 1 second of resize.

Adding perf keyword, assigning to pavlov as p3 for M16

Comment 8

[(not reading, please use [e-mail] instead)]

now I'm seeing what peter sees.

a delay is acceptable for beta (and on optimized bits, it will most likely be
less of a delay)

the delay may not even be a bug, we just may be slow.

perhaps we should change the bug summary, since I'm not seeing this anymore.

Comment 9

[lchiang]

Since it's just a delay, removing the beta1 keyword

Comment 10

[Peter Trudelle]

reassigning to don: Isn't this an XPApps thing?

Comment 11

[lchiang]

removing NEED INFO as this status whiteboard entry is out-of-date.

Comment 12

[Ninoschka Baca]

Build 2000-04-28-09M16: NT4
Build 2000-05-01-11M16: Linux 6.0, Mac 9.0
I don't see this problem. If noone else has seen this then I'd like to mark as 
Worksforme.

Comment 13

[(not reading, please use [e-mail] instead)]

marking worksforme.

let's assume pav / blizzard fixed this when they fixed the event starvation
problem that was horking mailnews.

Comment 14

[Ninoschka Baca]

Verified Worksforme.