Try grabbing the title bar in the latest build and dragging the window around. There is no visible redraw but on me PIII 350 I get about 2-3 fps.

Fine for me using viewer on NT. Changing component to XP Apps and re-assigning, because we don't layout (or shouldn't be anyway) during a move of the top-level window and so this isn't layout

spam: qa contact to jrgm@netscape.com

I believe danm pops a timer for the persisted attributes on the <window> every 500msec. I think that this is what leads to the 'jerky' behaviour when quickly dragging the mozilla window around the screen -- i.e., periodically, the window seems to stop following the mouse drag for a moment, and then repaints at the point the mouse has moved to during this "stall" period. (My tests on win2k for 2000041309 M16 Comm.) If I remove the ``persist="screenX screenY width height sizemode"'' attribute from the <window> in navigator.xul, this periodic "stall" in the drag goes away (of course). Bug or feature? :-] Either way, this is a not a major issue (but can give the app an appearance of sluggishness).

Yes, I've noticed this seems broken lately. The aforementioned timer is not supposed to fire while the window is still being dragged. Wants looking at...

moving to m18

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

I suspect this problem was caused by some regression in the timer code. I don't see this problem on today's build. Seems like someone has fixed it in the intervening months. Calling it fixed. Reopen (with copious explanatory notes!) if you disagree.

Verified