a peculiar cross-browser onresize quirk

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 🙂

Advertisements

10 thoughts on “a peculiar cross-browser onresize quirk

  1. Well… IE9 only has seems to have 4 events and when I uncheck the 'Read scrollWidth/scrollHeight during resize' option it has 0 events. (screenshots)It seems that IE9 has a quirk by not having a quirk 😀

  2. Since IE6 is still widely spread in China, did someone check the behavior in that browser? Not that it would help the site to work in modern browsers, but it would maybe clarify things up a bit.

  3. Originally posted by sirnh1:

    It seems that IE9 has a quirk by not having a quirk

    Well, if browsers accidentally reach a state of compatibility we sure work hard to go back to normal levels of quirkyness, don't we? 🙂 Though IMO the real quirk is the fact that reading scrollWidth/Height makes any difference at all, so by that measure IE9 is still quirky, only half as much.

  4. I fail to understand why the resizing script would still run. Shouldn't it set the state of the box and then quit?EDIT: In fact, shouldn't the box actually work BETTER in Mini? Just because of the limits on page scripting in Mini…

  5. Hallvord, it's not quirk at all.When you change height to some value and then to different one in same thread without doing "much" in between, then layout of elements will only be performed once, after script thread finishes.But if you access one of the many properties that require reflow to be performed (scrollWidth/Height are some of these) in between changing values, then this will have to trigger reflow so that correct, new values are returned.

  6. @diz: Interesting theory. What is setting height and width of an iframe to the empty string supposed to do anyway? …

  7. Originally posted by hallvors:

    Or perhaps work on heuristics for running only intelligently written JavaScript

    That's the disable javascript feature.If intelligently written javascript were to run, barely any js would run at all ! 🙂

  8. Rafal, you and me can tell why this happens – but try to find one single regular web developer / script author who would expect this behaviour! I call it a quirk because it's something a normal web author would neither expect nor understand.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s