Display overlap in Firefox when editing multiple tiddlers in reverse order

[draker]

This display bug produces results similar to #301, however it occurs even if EnableAnimations? is turned on.

A tiddler being edited is not displayed properly if it is moved as a result of another tiddler above it on the page subsequently being opened for editing.

Closing an existing tiddler, opening a new one, or even just resizing the Firefox window slightly triggers a refresh which clears up the display.

Steps to reproduce:

• Goto  http://www.tiddlywiki.com/ with Firefox
• view Raves
• view HelloThere?
• observe display

I'm using Firefox 1.5.0.9 under X11 in Linux.

Thanks!

[draker]

I just checked; same problem occurs with Firefox 2.0.0.2 in WinXP. MSIE6 is ok.

[EricShulman]

This problem was previously fixed by adding the "forceReflow()" function to perform a Gecko-only CSS hack that toggles the styles of the BODY element, forcing FireFox? to adjust the existing rendered content. However, I can't seem to locate a ticket that documents the addition of the forceReflow() function into the core (though I KNOW it was fixed about a year ago!)...

Unfortunately, this problem has apparently re-emerged. I suspect a recent FireFox? update has optimized the CSS handling in such as way that the two consecutive, *synchronous* calls to setStylesheet() in forceReflow() are being ignored.

To address this, I tried the following code change in forceReflow(), which I have tested by creating a small plugin that overrides the core-defined version of the function:

if(config.browser.isGecko) {

setStylesheet("body {top:0px;margin-top:0px;}"); setTimeout('setStylesheet("");',1);

}

Unfortunately, I am unable to generate an svn diff on my system (using TortiseSVN under WinXPSP2, which doesn't seem to have any command line apps!), so I will note the differences here:

* the first call to setStylesheet() now uses

top:0px;margin-top:0px;

instead of

top:-1em;margin-top:1em;

(this eliminates 'jitter' due to shifing the entire body element)

* the second setStylesheet() call is now performed *asynchronously* with a 1ms delay (this bypasses the presumed browser optimization).

Because I have not built a local test version of the core, I have NOT submitted this code change to SVN, though I think it is a 'good fix'.

[EricShulman]

Here's the full code for the fix... I am currently unable to generate a proper patch file, and apparently don't have permissions set to allow me to checkout/checkin from Trunk/core/js :-(

// Force the browser to do a document reflow when needed to workaround browser bugs
function forceReflow()
{
	if(config.browser.isGecko) {
		setStylesheet("body {top:-0px;margin-top:0px;}");
		setTimeout('setStylesheet("")',1);
	}
}

[JeremyRuston]

Fixed in changeset:4612