While working on understanding an input problem on a section of the Chinese qq.com site, I wanted to understand when the resize event fires for IFRAMEs. In particular, if width/height of the IFRAME are set by a script to its current values, will a resize event fire?
Trying to build a minimal test case, I had a hard time reproducing the resize events that were fired on the live site. On the site, onresize fired twice. I assumed it happened once when width/height was set to an empty string, and once when they were reset to original values. But why didn't this happen in a test doing those two things?
Gradually including more code from the live site, the penny dropped: simply reading scroll dimensions from the inside document, caused extra calculations of the document's dimension that wouldn't otherwise occur. As a side effect of this, resize events would fire. Very quirky..
Well, we're used to quirks – we're dealing with web browsers, after all. But here's the weirdest part: this very obscure and quirky behaviour happens in all four major browser engines! Check the testcase – Opera, Chrome, IE8 and Firefox all fire 8 events for 4 resizes if you read scroll dimensions while the script runs, no events otherwise. So there, a cross-browser compatible quirk! And Opera's bug is not that we fire too many resize events – it is that we need to remember cursor position and re-focus the element when contentEditable is toggled off and on again.