Closed Bug 125795 Opened 23 years ago Closed 23 years ago

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

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: kriskelvin, Assigned: dcone)

References

(
URL
)

Details

(Keywords: regression, testcase, top100)

Attachments

(3 files)

test case showing grey
395 bytes, text/html
Details
another sshot, this time showing later descriptions in bug 126077
183.91 KB, image/jpeg
Details
initialize variable.
1.16 KB, patch
kmcclusk
: review+
attinasi
: superreview+
Details | Diff | Splinter Review
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. ***
Keywords: mozilla0.9.9, nsbeta1
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: nsbeta1 → nsbeta1+
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"
Blocks: 126175
Blocks: 126238
Blocks: 126218
Blocks: 126358
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: 23 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.

Attachment

General

Creator:
Created:
Updated:
Size: