> 2. On the left, note the style sheet switcher. the "abc" blocks... > 3. Select style 3 (green + white) with linux trunk 20030612 and firebird 0.6, the style switched immeadiately and without incident. > 4. Re-visit the page (do not reload the page) still looked ok.
I was able to reproduce this bug on Windows XP, SP1. This might not be the case in the Firebird Linux Distro.
Allow me to clarify: 1. Visit the default page (www.zeldman.com) 2. On the left, note the style sheet switcher (abc, abc, abc...). 3. Select style 3 (green + white) 4. Re-visit the page (do not reload the page). Do this by clicking the location bar and pressing enter/return. 5. The menu bar at left will not render when the page is loaded. 6. Reload the page to work around.
seen this myself in cvs builds of Firebird from the trunk, Linux
Confirming new based on previous comments. OS->All based on comment 4 I've also seen this in Firebird 20030614 PC/WinXP but couldn't always reproduce. I don't even use the style switcher on that site.
I can verify this on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030616 Mozilla Firebird/0.6 and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030602 Mozilla Firebird/0.6. The div in question seems to be id="secondarynav". I'll see if I can find a smaller testcase.
Created attachment 125763 [details] Screen grab of zeldman.com showing bug behavior, Mozilla 1.4 RC1 Windows XP Pro SP1
I had encountered styleswitcher quirks using (I believe) the same script (or a variation thereof) at http://kapowaz.diaryland.com/ which I think exhibits similar problems; in particular the height of elements containing background images doesn't change until the page is reloaded.
It might be related a bug I reported: bug 209217, in which some div's take the wrong values when upon a stilesheet change. This doesn't quite seem the same, as it doesn't happen constantly, and requires you to revisit the page, etc.
er, bug 207716... sorry.
Transferring to positioning. I think your assessment may be correct, Mike; the <div> is absolutely positioned, DOM Inspector shows it with the correct computed styles, but once it breaks it takes an initial reflow to trigger the proper display.
This may well get fixed by bug 193069 (some of the fun-n-games in bug 193014 may be involved).
Fixed by patch in bug 200931