Closed Bug 209217 Opened 18 years ago Closed 18 years ago
Portions of markup do not render (invisible) after cookie set for alternate style sheet
> 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
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.
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.
Assignee: other → position
Component: Layout → Layout: R & A Pos
This may well get fixed by bug 193069 (some of the fun-n-games in bug 193014 may be involved).
Depends on: 193069
Fixed by patch in bug 200931
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.