Outfox the Firefox?

[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

[Diver]

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

[expat]

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

[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?

[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.

[NickFitz]

Actually, looking into this in more detail you've got a tableset with this div and td.controlbar in there as well. '.vBulletin_editor' is 100% width and the whole cell is keeping its width when you reduce the size of the browser window, leading to this overlap. You could take away the tables and use relative positioning, giving the right-hand boxes a lower z-index so if they do overlap, they go under the editor box.

I think it's the iframe that's called in the td class 'controlbar'. this code here:<iframe style="border: 2px inset ; width: 540px; height: 250px;" tabindex="1" id="vB_Editor_001_iframe"></iframe> that may be causing the problem.
It's not something I can correct using CSS alone - a change has to be made to the template. Sorry.

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.)

[realityhack]

Is this your entry in the nerd of the week competition?

I think it's the iframe that's called in the td class 'controlbar'. this code here:<iframe style="border: 2px inset ; width: 540px; height: 250px;" tabindex="1" id="vB_Editor_001_iframe"></iframe> that may be causing the problem.
It's not something I can correct using CSS alone - a change has to be made to the template. Sorry.

[DiscoStu]

Actually, looking into this in more detail you've got a tableset with this div and td.controlbar in there as well. '.vBulletin_editor' is 100% width and the whole cell is keeping its width when you reduce the size of the browser window, leading to this overlap. You could take away the tables and use relative positioning, giving the right-hand boxes a lower z-index so if they do overlap, they go under the editor box.

Is this your entry in the nerd of the week competition?

[realityhack]

Actually, looking into this in more detail you've got a tableset with this div and td.controlbar in there as well. '.vBulletin_editor' is 100% width and the whole cell is keeping its width when you reduce the size of the browser window, leading to this overlap. You could take away the tables and use relative positioning, giving the right-hand boxes a lower z-index so if they do overlap, they go under the editor box.

[realityhack]

Mods - if you make the class '.vBulletin_editor' fluid it should fix this problem. Try experimenting with a % width inside the 'panel' class.

[expat]

In IE there is a horizontal scroll bar at up to about 1100 pixels width, in Firefox up to about 950 pixels.

In IE the grey bit the smileys are on is unobscured. The white "contractor alliance" and other advert boxes are to the right.

In Firefox, they float further in and float under the smileys but over their grey box.

Well, that's pretty well what I noticed. But it does not seem tome to be "correct" in termes of what I would expect a browser to do.

Still, I learned on Script/VS so what do I know?

[BrowneIssue]

In IE there is a horizontal scroll bar at up to about 1100 pixels width, in Firefox up to about 950 pixels.

In IE the grey bit the smileys are on is unobscured. The white "contractor alliance" and other advert boxes are to the right.

In Firefox, they float further in and float under the smileys but over their grey box.

[expat]

Depends on your screen resolution.

Ta, but I thought that the whole point of the Markup/Browser model was that I got to decide that?

It's 1024 x 768 on this machine.

[TheFaQQer]

Depends on your screen resolution.

[expat]

Why are the smileys over to the right in 3 columns with the rightmost over the CUK Navigation links?

Is it CUK that is wrong, Firefox that is wrong, or is it just an administrative oversight, nothing to see here, just leave it to us?