Closed Bug 125795 Opened 18 years ago Closed 18 years ago

Part of page text appears in dark grey color, wher supposed to be other color

Categories

(Core :: Layout, defect, major)

x86
All
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: kriskelvin, Assigned: dcone)

References

()

Details

(Keywords: regression, testcase, top100)

Attachments

(3 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8+) Gecko/20020215
BuildID:    2002021503

While visiting the above page, part of its text each time appears in dark grey
where it is supposed to be something like light blue ore white. Scrolling up and
down the window helps sometimes, but other text gets grey that time. 

Reproducible: Always
Steps to Reproduce:
1.visit above page
2.look for dark grey text (there is no text of this color by its code)
3. scroll page up and down or
3a. Klick on link and press back button of browser. 

Actual Results:  part of text rendered in dark grey

Expected Results:  Text rendered in color defined in code of page
I actually don't see what is happening at the page you mentioned, but I do see
it happening at this page:
http://expert.cc.purdue.edu/~ariel/links.htm

It looked fine with 2002-01-30 but now with 2002-02-15 it shows the same problem
you describe. If I focus the URL bar, or move the mouse over the links, it fixes
some parts.

Changing to NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
I see this too on Windows XP with today's build...
I'm seeing this as well with 2002021503 on Win2k.

Some text marked as (font color=#ffffff) shows as dark grey whenever I focus on
something other than the frame containing it, disappearing when highlighted.

Also seeing it on visited links with the body tag vlink=white. The underline
itself is white, but the text is dark grey. It may be notable that unvisited
links (body link=white) on the same page are just fine. Of course, Ariel's
example (and perhaps the other) reveal that the "real" colour doesn't need to be
white.
Seeing it in FreeBSD (linux build 2002021513) as well.
Attached file test case showing grey
this HTML shows the "link link link" and "wibble" in dark grey for me
consistently, using 2002021503 on win2k.  having asked in #mozillazine, other
folks using recent nightlies on win95, winME and a linux cvs build see this
test case correctly (yellow and white).  anyone else see this bug happening
with my test case?
Michael, I see this bug in your test page with 2002021503 on win 98

The concerning texts are grey. The line underlining the link however is yellow.
The test case works correctly (yellow) for me in 2002021503 WinME
The test case fails (grey) in 2002021608 WinME

I'm also seeing some grey headers (should be white) at http://slashdot.org/ in
2002021608 WinME
*** Bug 125908 has been marked as a duplicate of this bug. ***
Changing OS to ALL, and adding Keyword top100 because it has been observed in
Slashdot and Hotmail
Keywords: top100
OS: Windows 98 → All
I only began to notice this bug since I started installing daily builds over
0.9.8.  Now running 2002021608 on win98.  on dark backgrounds I find that the
text will either be invisible (same as background color) or a dark blue or black
color.  Selecting and then unselecting the text will usually correct the color
issue, but not consistently.
2002021608 has it also. www.gamefaqs.com has a bad case of it.
Severity: normal → major
Keywords: regression
Keywords: testcase
Looks like I put in a dupe of this.  Check out my screenshot attachment on bug 
#126077.  Also, I tried putting a lot of descriptions in that bug that may help 
isolate what's going on.
*** Bug 125853 has been marked as a duplicate of this bug. ***
*** Bug 126077 has been marked as a duplicate of this bug. ***
This also happens in mail.
I see it when select text (in a plain text message).
Some lines will be white (normal), others will be gray (not normal).
If it's any help I didn't see it on BuildID 2002021210 but do on 2002021510.
Reassigning to Don. My guess this is related to code which darkens the
foreground colors when printing. Don, is it mistakenly using the printing logic
when rendering  to the screen?

nsbeta1+
Assignee: attinasi → dcone
Keywords: nsbeta1nsbeta1+
Target Milestone: --- → mozilla0.9.9
I'm getting worried that the more this bug progresses, the more it sounds like 
my bug 126077 may *not* be a duplicate after all.  Can anyone that's seen what 
this bug is talking about confirm or deny whether they've seen it 
effect "partial" areas like the screen shots I've posted?

http://bugzilla.mozilla.org/attachment.cgi?id=70005&action=view
I started seeing the problems shown in
http://bugzilla.mozilla.org/attachment.cgi?id=70005&action=view
 in the same build (2002021608) that caused the attached test case to start
displaying incorrectly so I assume they are related if not the same problem.
I see this problem on several sites, most notably slashdot and mozillazine.
Ah - ok, thanks Luke!  So both problems started in the 15 nightly build?

Is there any current method for getting builds that are the previous nightly
plus 1 patch each?  I know this would mean N builds for N commits that day, but
if this is possible and it could narrow down the problem to one patch, I think
we'd be much better off.  I wouldn't mind applying the patches manually, but it
sounds like doing all the compile options correctly is a beast, and I don't have
a build env for Win2k at the moment anyway.

Thanks!
yes.. there is a variable that is not initialized.. I have the fix.. and will 
check in when the tree opens.
Comment on attachment 70100 [details] [diff] [review]
initialize variable.

sr=attinasi  BUT, why don't you want to initialize all of these variables?
Attachment #70100 - Flags: superreview+
Those other variables.. displaySelection and isPagenated are initialized by the 
function "GetTextInfoForPainting"
The various bugs this blocks are all likely duplicates that should be tested
once this bug is fixed.
Adding another dupe-candidate ... will test when patch is checked in.
Blocks: 126012
Blocks: 126298
fixed
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
*** Bug 126425 has been marked as a duplicate of this bug. ***
Weird, I reopened the bug 96870 indicating that the variables were not properly
initialized, but for some reason nobody was paying attention for a while...
Blocks: 59652
*** Bug 126431 has been marked as a duplicate of this bug. ***
*** Bug 126298 has been marked as a duplicate of this bug. ***
*** Bug 126218 has been marked as a duplicate of this bug. ***
*** Bug 126012 has been marked as a duplicate of this bug. ***
Marking verified with the April 12th trunk build (2002-04-12-10).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.