Closed Bug 135113 Opened 19 years ago Closed 19 years ago

Rendering problem when switching to alternate stylesheet

Categories

(Core :: CSS Parsing and Computation, defect)

x86
Windows NT
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 63863

People

(Reporter: portegie, Assigned: dbaron)

References

()

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031104

When switching to an alternate stylesheet (either from the View menu or with a
JavaScript styleswitcher accessed from a web page), the background is rendered
incorrectly.

Check out my home page, http://carol.wins.uva.nl/~portegie/ . When switching
from the (default) Grayscale style to the Commodore 64 style, the background
remains white. If the style is set using the drop down list in the upper right
corner, clicking anywhere in the page corrects the problem. However, when the
switch was invoked form the View menu, only clicking in the drop down list
corrects the problem.

The same thing happens when switching back to the Grayscale style - the
background now remains blue as in the C64 style.

Weirder still: one the 3l33t style has been chosen once, the problem disappears,
until the page is reloaded.

A similar problem occurs on http://www.arsware.org/ .


Reproducible: Always
Steps to Reproduce:
1. Go to http://carol.wins.uva.nl/~portegie/
2. Change the style to "Commodore 64" using the drop down list in the upper
right corner.
3. Click anywhere in the page.
4. Switch back to the "Grayscale" style.

Actual Results:  After step 2, the body background color remains white.

Expected Results:  The body background color should have changed to a bluish purple.

This did not happen using 0.9.7 on this machine. This bug was first encountered
after a clean install of 0.9.9.
this worksforme in linux trunk build #2002040302

please test this in a recent nightly. 
WFM on BuildID 2002032810 on Win XP Pro
 As requested I downloaded the latest nightly build (ID 2002040203), and the
problem does not occur anymore.

Thanks,

Joris
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
verified based on comment, but note that the correct resolution is really
WORKSFORME, not FIXED. The latter is only allowed when a specific patch is known
to have fixed the bug.
Status: RESOLVED → VERIFIED
Reopening.
Status: VERIFIED → UNCONFIRMED
Resolution: FIXED → ---
...and marking as duplicate of the bug where the problem was fixed.

*** This bug has been marked as a duplicate of 63863 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.