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?
The script I was looking at intended to resize the IFRAME to fit its contents. To do so, it set with/height of the IFRAME to an empty string, read scrollWidth/scrollHeight of the document inside, and set width/height to the values it had read. Meanwhile, in another and odder part of their JavaScript, an onresize listener would toggle contentEditable for the element you'd type your status update in off and back on again each time the resize event fired! I can sort of understand the logic of the IFRAME resize part, but I don't have a clue why they would turn contentEditable off and back on for every resize.. This made the input cursor go away for every resize, and since the script "resized" the IFRAME for every single keypress, typing anything at all was pretty hard..
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.
Or perhaps work on heuristics for running only intelligently written JavaScript :)
