This spun from bug 114649 comment 50. Initial conditions ------------------ Make sure your Windows os setting Start/Settings/Control Panel/Category: Appearance and Themes/Display/Appearance tab/Effects... button/Show window contents while dragging checkbox is checked Steps to reproduce ------------------ - load attachment 245856 [details] - resize horizontally and vertically the window (also called window corner resizing the window) Expected results ---------------- onresize events should fire continuously while the window is resizing horizontally and vertically Actual results in Seamonkey 2.0a2pre rv:1.9.1b2pre build 20081009 under XP Pro SP3: onresize events do NOT fire continuously while the window is resizing horizontally and vertically Notes ----- - Internet Explorer 7, Opera 9.60 build 10447, Safari 3.1.2 build 525.21, Google Chrome 0.2 and Konqueror 4.1.1 get the expected results - This bug is Windows os only - Component is the same as in bug 114649: Layout ... (although it probably should be DOM Events) adding testcase keyword

I wanted to just mention that I don't think Opera 9.62 (windows) is getting really "continuous" repaints... If I try the suggested attachment in OP9.62win, and I corner resize the window pretty quickly, I get no updates to the text boxes until right after I stop (or pause even for the briefest of moments). Actually, I think it's that Opera puts all javascript (timers, events, etc) on hold while it is resize redrawing, and then all updates happen in order, as if in a queue waiting to execute. Perhaps this same behavior is *not* the behavior we want to copy in FF, but more like IE's way of continuous event firing, where it's truly continuous and not just queued-continuous.

Sorry, I was getting this bug mixed up with a different one.

Seems Bug 457862 fixed this for 1.9.2. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090107 Minefield/3.2a1pre

Although the comments from #Bug 114649 seem to indicate that this is tied to Windows setting, what I have seen is that while the FireFox window is getting resized and onscreen elements are getting redrawn, the auto margins of elements are changing on screen, resize events are not fired. Obviously this not right which ever way the Windows settings are, since what are happening within FireFox window itself is a contradiction: either you do not redraw on-screen elements and do not fire the resize events, or you redraw them and fire the events. You just can't redraw on-screen elements and NOT fire the resize events at the same time.

I'm not convinced this is Windows specific; I can reproduce the symptoms on Ubuntu 12.10, gnome 3.6. While Chromium updates the window contents seemingly in realtime (even IE8 in a VM seems more snappy!?) Resizing the window and running http://getify.com/infobox/test-opera-resize.html If I resize it fast, over hundreds of pixels, the updates come at the end and there are few of them. If it does redraw while resizing the events are far enough apart that it looks jerky, and the window has time to move while thats onscreen. Unscientific test using the page above, resize window to a quarter of it's size: Firefox: *rrr_*rrrrr_ Here is some filler text. (Most of these displayed after I'd finished resizing) Chromium: *rrrrrrr_*rrrrrrrrrrrrrrrrrrrrrr_*rrrrrrrrrrrrrrrrrrrrrrr_*rrrrrrrrrrrrrrrr_*rrrrrrrrrrrr_ Here is some filler text.

Folks, Can someone confirm if this bug exists under Windows 7 ? under Windows 8.1 ? under Windows 10 ? Thanks. Over here, I get expected results under Kubuntu 14.04.02 LTS, Linux 3.13.0-55-generic x86_64 .

I have tries the above test in FF 38.0.5 under windows 8.1 and I got this while resizing to 1/4 size. *rrrrrrr_*rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr_*rrrr_*rrr_*rrrrrrr_ And it looked smooth. I also tested the original attached example and events fire multiple times a second at least (to fast to even distinguish.

(In reply to David Mårtensson from comment #8) > I also tested the original attached example and events fire multiple times a > second at least (to fast to even distinguish. That's good enough then. Resolving as WORKSFORME