I was playing with a Web application that did interesting redrawing of the layout (e.g. needed to do JavaScript magic in the onresize event).
I noticed that in Firefox the event took a fair time to fire. Joel Webber (of GWT fame) has also found this and said:
“Firefox and Opera do this wierd thing where they only fire resize events when you let go of the mouse button, or every second or so while dragging. It’s really irritating because there’s no way to get a “real” resize event, and it makes your ui look crappy when it goes through intermediate wrong-sized states.
I’ve always assumed this was to cover up layout performance issues. WebKit and IE fire resize events immediately.”
I wonder if the layout issue is correct, and if so, it would be nice to be able to somehow say to the browser “yup, I am in control of layout so please fire faster” or maybe by defining onresize you are saying that.
With decorators/annotations you would say:
@FireFrequency(ms=10) window.onresize = function() { // .... }
Turns out that Ben was being a good citizen and in going to file a bug, found a couple out there.
December 31st, 2008 at 11:12 am
I just faced this issue a week ago or so, and it is indeed very irritating. I found an ugly way to deal with that: I set an window.onmouseout event to a function which will schedule a call for my normal window.onresize event every 20 ms; then I set a window.onmouseover event which will clear this job.
In fact, I decided to do that because the first thing you do when you are going to resize the window is to point with your mouse at the lower right of the browser window; at the same time, we can be sure you won’t resize the window when your mouse is over the window. Yet, this can lead to thousands of unnecessary calls.
The result is not as good as with a simple window.onresize on Safari, for instance, but it is much better in Firefox like this.
Quite an ugly hack, indeed, but if you think we can handle it better, let me know what you think.
Of course, a bug fix from Firefox and Opera would be much better…
December 31st, 2008 at 11:18 am
I’ve filed a couple of related bugs about this with Opera before (in fact, I mentioned that the behavior found was similar to that of FF!). Still no response from them, several months later.
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.
December 31st, 2008 at 11:31 am
FYI-the more I study FF’s particular behavior, the more I think it’s NOT the same queuing that is clearly evident in Opera. It might still be the case, but in Opera a *first* onresize does happen right away, which gets the collecting of “r” chars started so that as the continous motion occurs, the “r” chars build up. But with FF, that first onresize event doesn’t happen, so the 3-6 chars that DO show getting built up occur between the one ending resize event and the time (~50ms later) that I turn off the interval listener. So, for FF, this is probably not the queuing that Opera shows, as I suggested above.
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.
December 31st, 2008 at 12:37 pm
Weren’t there some recent changes to this?
I just can remember if they were 3.0 recent or 3.1 recent…
December 31st, 2008 at 1:24 pm
https://bugzilla.mozilla.org/show_bug.cgi?id=114649
January 1st, 2009 at 1:21 am
I raised a query about Firefox’s resize behaviour a while back. At the time I cared how the resize event behaved. Now I don’t care, I just want it consistent with other browsers, whether those other browsers are ‘broken’ or not.
January 2nd, 2009 at 3:41 am
I too noticed this issue some time back
January 3rd, 2009 at 3:35 am
https://bugzilla.mozilla.org/show_bug.cgi?id=114649
January 4th, 2009 at 7:40 am
https://bugzilla.mozilla.org/show_bug.cgi?id=114649
January 7th, 2009 at 1:53 pm
Was the app you were playing with ptable.com?
January 9th, 2009 at 6:30 am
I was reading your conversation hoping to find a solution to my problem
I’m using a table with 3 cells – left cell positioned at 50% of page height & right one at 50%. The side cells have their heights set to match the upper or lower border of the middle cell. When I resize the browser all goes well as long as the browser inner height is an integer value eg 15 or 347 but when the browser height is a float eg: 15.5 or 347.5, my side cell’s heights are set 1 px to low.
I was hoping to solve this with window.onresize in javascript but it is firing to many times to be reliable. Do you guys know how to deal with this issue in different browsers?
I’m just a beginner using VS2005 to get this job done. Thanks in advance and kind regards to you all.
Jacek