Outfox the Firefox?

[realityhack]

What he said

FWIW it does the same in Safari and Opera - can't be bothered to check the crock of tulip that is IE.

If it is coping in IE 6 and 7, then it's a good demonstration of the first rule of page layout: if it looks right first time in IE then you have done it wrong. Get it looking right in the browsers that work properly (Firefox, Opera, Safari, Konqueror et. al.) and then see what IE bugs have been triggered and apply the necessary fixes in such a way as not to affect the real browsers.

(Hint: applying "zoom: 1;" to the relevant block-level containers is usually all that's necessary, unless you start running into things like the Three Pixel Text Jog, the Magik Creeping Text or the phenomenally stupid IE7-crasher I identified over the last few days, and haven't yet reduced to the absolute minimum test case - when I say "crasher", I mean "The task is not responding" style crash.)

It breaks in IE7 - curiously the overlap goes over, not under the tds to the right.
I think the templates are more of an issue here - the form is likely to be hard-written into the php so making structural changes would mean getting under the bonnet of the vb software itself. The general chatter is Drupal as an alternative, to output code separating content from presentation entirely. For instance - that iframe's fixed width throws everything else around it out, regardless of properties given to the containing elements. I did try, but CSS alone won't fix this.

[Ardesco]

What he said

FWIW it does the same in Safari and Opera - can't be bothered to check the crock of tulip that is IE.

If it is coping in IE 6 and 7, then it's a good demonstration of the first rule of page layout: if it looks right first time in IE then you have done it wrong. Get it looking right in the browsers that work properly (Firefox, Opera, Safari, Konqueror et. al.) and then see what IE bugs have been triggered and apply the necessary fixes in such a way as not to affect the real browsers.

(Hint: applying "zoom: 1;" to the relevant block-level containers is usually all that's necessary, unless you start running into things like the Three Pixel Text Jog, the Magik Creeping Text or the phenomenally stupid IE7-crasher I identified over the last few days, and haven't yet reduced to the absolute minimum test case - when I say "crasher", I mean "The task is not responding" style crash.)

http://blogs.msdn.com/gpde/pages/javascript-memory-leak-detector.aspx

Something related to the above?

[expat]

...the first rule of page layout: if it looks right first time in IE then you have done it wrong.

[Diver]

I'm running Firefox on Vista, no problem here.

[NickFitz]

http://blogs.msdn.com/gpde/pages/javascript-memory-leak-detector.aspx

Something related to the above?

Nope, this is deep down inside the rendering engine. It's a well-formed HTML page with valid CSS; when a className is changed to dynamically hide certain elements (while un-hiding others) at a lower level the rendering engine goes into an infinite (or at least indeterminately lengthy) loop. Or to be precise, it does if those elements are actually visible in the browser window; if they're currently scrolled off screen, it doesn't enter the infinite loop until they are scrolled into view, and if they never are brought into view it doesn't crash at all.

However, before they are in view, use of MS's DOM inspector reveals that the browser thinks they are somewhere up by the top left of the window (not the page, but the actual top left of the window, as if they had "position: fixed;" set), although it's unable to render their actual content there, and they don't appear in any z-index related stacking order.

The fix is to also toggle a garbage className on the parent element of the things it's having trouble re-rendering. This forces it to do a reflow on that element before attempting to reflow the outermost container, which allows it to get its internal data structures (the ones below the level of the DOM structures exposed to the outside via COM) into a coherent state, with the result that everything works properly again. This also has the virtue of having no unpleasant side effects on other browsers (assuming the garbage className isn't one referenced in any CSS, of course - something like "sodding-ie-reflow-trigger" does nicely ).

Interestingly, it's the second time I've come across virtually the same bug in IE 7 in the last two weeks, although the last one wasn't a crasher; this is why I need to work on producing a minimal test case to allow me to determine the precise trigger(s) before publishing my findings.

Once I realised that I needed to force the rendering engine to do an unnecessary reflow, I thought of the dummy className technique. Then, today, I found that it also worked to fix a problem IE 6 was having with something different, so it's a potentially useful technique in a number of situations.

And, because all browsers have a similar need to do a reflow when dynamic stuff happens, it's quite possible that it might be useful for dealing with odd layout problems in other ones - after all, none of them are perfect