51066 - page colors not updated when Use Windows Colors is checked

Status: VERIFIED DUPLICATE of bug 90081

(SeaMonkey :: Preferences, defect, P3)

Description

[fantasai]

Overview:

	When the text and background colors are changed in the preferences
	dialogue, the changes are immediately affected in the document being
	viewed. However, this does not happen when the "Use Windows Colors"
	box is checked; the page colors do not update until the page reloads.

Steps to Reproduce & Actual Results:

	1. Open up testcase (to be attached shortly) in Mozilla.
	2. Go to the Preferences and change the background to black and the
	   text to lime green. (Assuming your system colors aren't black and 
	   lime green.) Confirm changes. The background and text color
	   on the page will change.
	3. Go back to the Preferences and select the "Use Windows Colors" box.
	   Confirm changes. The background and text color on the page will not
	   change.
	4. Reload the page. The colors will change.

Expected Results:

	The page colors should be immediately updated; one should not have
	to click the reload button.

Tested on Mozilla nightly build (id: 2000083111) on Windows 2000.

Additional Comments:

	This is not a dupe of bug 22963, even though a similar issue is 
	mentioned there.

Comment 1

[fantasai]

Attachment: testcase

Comment 2

[sairuh (rarely reading bugmail)]

ian/beppe, yet another color pref bug...

Comment 3

[matt]

background color problem

Comment 4

[don]

No, the colors ARE updated.  Sairuh and I just validated this.  However it does
exacerbate bug #22963 if this pref is turned off.

Comment 5

[sairuh (rarely reading bugmail)]

actually, the colors were updated on don's win98 laptop. when i double-checked
this on winNT [2000.09.20.05 opt comm] this is what i see:

1. in Colors pref panel deselect the "use windows colors" checkbox.
2. change the text color (aka, foreground color) to something other than black
--i chose a lively lime green.
3. save/exit prefs by clicking OK button. observe that the text color hasn't
really changed.
4. however, bring up the prefs again, and notice that the tree text color is now
lime green (bug 22963).
5. select the Colors panel again.
6. check the "use windows colors" checkbox.
7. save/exit prefs.
8. re-enter prefs. observe now that the tree has the black text --to me, this is
saying that the "use windows colors" pref is working.

so, i'm verifying this bug as wfm.

Comment 6

[fantasai]

Reopening bug.
I'm still seeing this; in the past week I've tested three different builds on 
two different computers, one on WINNT4 and the others on WIN2K--including 
today's build after having erased my hard disk over the weekend.

I think maybe the bug report was not clear enough. The point is that the colors 
are not immediately updated upon exiting Prefs when you choose system colors. 
It's not triggering a repaint or something--on the page I mean, not the chrome.

Steps:                                                 Observation:

  1. Set preferences to use Windows colors if             none
     not already so.

  2. Open up testcase in Mozilla.                         text - WindowText
                                                          bg - Window

  3. Open Edit > Preferences, select Colors.              text - [violet]
     Set bg & text to other colors (e.g violet &          bg - [lime green]
     lime green) and uncheck system color pref.
     Exit Prefs.

  4. Open Edit > Preferences, check system                text - [violet]
     color pref. Exit Prefs.                              bg - [lime green]

  5. Hit reload.                                          text - WindowText
                                                          bg - Window

Notice the lack of immediate color change in step 4, requiring a reload to 
update the page colors.

Comment 7

[Chris McAfee]

matt

Comment 8

[sairuh (rarely reading bugmail)]

methinks this is a dup of bug 90081 [newer bug, but has more recent activity].

*** This bug has been marked as a duplicate of 90081 ***

Comment 9

[sairuh (rarely reading bugmail)]

mass verification of duplicate bugs: to find all bugspam pertaining to this, set
your search string to "DuplicateBugsBelongInZahadum".

if you think this particular bug is *not* a duplicate, please provide a
compelling reason, as well as check a recent *trunk* build (on the appropriate
platform[s]), before reopening.