User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 The textcolor on the URL given is not consistent with each view leading me to believe that it's a bug. Looking at http://www.technologyreview.com/style/global.css I find confusing CSS .. an example : .articlebody have it's color set to #000000 but .articlebody:link .articlebody:visited .articlebody:hover are all set to #333399 Allthough confused about what is the correct color (black or blue ?) I feel that Mozilla should always render it the same way. The first time i loaded it everything was blue allthough when I moved the mouse i noticed some parts turned black. When i reloaded everything was black but changed if I hovered or marked or scrolled the page. Reproducible: Always Steps to Reproduce: 1. load up http://www.technologyreview.com/articles/atwood1202.asp 2. Move the mouse over the page 3. Scroll down 4. move the mouse 5. reload 6. select some text 7. unselected it 8. goof around as you so desire Actual Results: The textcolor changes in a manner that defies logic Expected Results: Rendered the color the same way everytime.

.articlebody:hover { } applies to the span when the mouse is inside of it. So it should go into the :hover state whenever the mouse is in it. (And we can define "in it" however we want, since the HTML is invalid.) So the color should definitely change when moving the mouse. However, it looks like the style data are changing but we're not repainting (i.e., not invalidating enough). I can see this when selecting and when exposing parts of the window by clicking-to-raise. bz, could this be related to your recent improvements to reresolution over {ib}? Do we need to fix ApplyRenderingChangeToTree as well?

Yes, we do. That's what the patch in bug 146409 comment 27 does. With that patch, all the bugs that one blocks are fixed as well (as is this one).

fixed by checkin of bug 146409