NOTE: It may still be underlying a behavior that exists, but the construction of my my test masks it for FF since that first onresize never occurs.

Sorry if my original post is off-target or misleading, but was hoping it might trigger some thought toward an appropriate solution for FF.

I sure hope that maybe FF will address it at some point. I agree it’s quite annoying to not have the ability to rely on this event reliably between browsers.

—————–
To be more specific on the bug I filed, as it may have some relation to FF’s behavior: one workaround that is sometimes attempted is to have a quickly-executing interval (say, 35ms) which fires “continuously”, starting with the first onresize event, and ending some time (like 500ms) after the “last” onresize event, and accomplishing the same thing, or at least hoping to.

The problem is that Opera seems to queue up events (including timer events, and onresize events) while a continuous resize motion is happening, and only let them happen when it gets some breathing room with a brief pause in the resize motion. So, at least for Opera, neither the resize event, nor a continuously firing interval, can achieve the continuous reflow behavior that is desired.

I mention all this to say, perhaps FF is doing something similar, not specifically waiting for 1 second, but merely just queuing up resize events to be executed when a brief (even few ms) pause in the motion of a user resizing the browser occurs. In my testing, it seemed this brief pause can even occur in the short interval of time it takes to change direction with one’s mouse (from dragging the window bigger, to dragging it smaller). That few ms seems to be long enough for the browser to let some of those queued up events go ahead and execute.

And btw, the way I know the events are queued up is that I set up a test to see if there’s only one resize/interval event at the end, or several stacked up and later executed all on top of each other — it was clear from this test there were a bunch stacked up waiting to go out. That test link I set up (for the opera bug report) is here, and may be similarly useful for looking at (and fixing!?) FF’s behavior:

http://getify.com/infobox/test-opera-resize.html

Now, when I try this in Opera vs FF3, I do get different behavior… In Opera, the longer I do a continuous resizing, the more “r” characters will eventually get printed, with a single “*” being printed when the end of the interval hooking occurs. In FF, the number of “r” characters seems to vary only slightly with short or prolonged continuous resizing, sometimes 3, 4, 5 or 6 “r” chars at most.

But notice that the “r” characters never get shown until you “pause” in your movement… if you keep smoothly moving the “r” chars don’t get shown. This suggests the queuing I am referring to. But it does appear that FF limits the number of events in that “queue” to 5 or 6, whereas you can easily with opera build up 20 or 30 in that queue.