Closed Bug 246213 Opened 20 years ago Closed 20 years ago

background colors and images are not displayed/rendered/shown

Categories

(Core :: Layout: Tables, defect, P1)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: robert.a.lindley, Assigned: aaronlev)

References

(
URL
)

Details

Attachments

(9 files)

are we talking about the green quotes on the right???
23.47 KB, image/png
Details
That´s how I see it (excite.com)
16.12 KB, image/png
Details
Bugzilla Bug 246213
39.76 KB, image/png
Details
ScreenShot (png file)
17.14 KB, image/png
Details
testcase
1.63 KB, text/html
Details
testcase seen with Firefox 1.8a2 2004061113, working
9.51 KB, image/png
Details
regressed again: Firefox 1.8a2 20040613-09
9.39 KB, image/png
Details
ScreenShot-2 (png file) browsed of quirks mode
14.79 KB, image/png
Details
This fix probably works for NT, but I don't know about Win 98.
1001 bytes, patch
mkaply
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a2) Gecko/20040609
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a2) Gecko/20040609

Just installec this new version of Mozilla. 

In http://www.excite.com using MS IE, Netscape, and 1.6 version of Mozilla the
stock quote numbers show up as red, green, or black. 

This new 1.8a2 Mozilla all stock quote numbers are black.

Reproducible: Always
Steps to Reproduce:
1. Log on to site, look at stock quote numbers.
2.
3.

Actual Results:  
No color on stock quote mumbers

Expected Results:  
Show down numbers as red
Up numbers as green
Down numbers as black




No Crash, just missing color.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040609 Firefox/0.8.0+
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040610 Firefox/0.8.0+

In recent firefox-trunk-win32-zip, similar bugs were found on Win98SE:
Web pages do not show the colors indicated in CSS, body element, etc.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040608
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040613

tested on different computers under Win98 and Win98SE:

working:    Firefox 1.8a2: 2004060809
regressed:  Firefox 1.8a2: 2004060908
regressed:  Firefox 1.8a2: 2004061010
working:    Firefox 1.8a2: 2004061113

working:    Mozilla 1.8a2: 2004060809
regressed:  Mozilla 1.8a2: 2004060908
regressed:  Mozilla 1.8a2: 2004061303

testcases in Bug  246205 links not shown over td background images
http://bugzilla.mozilla.org/attachment.cgi?id=150541&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=150545&action=view

Bug is easily seen on:
http://www.mozilla.org/products/firefox/
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
http://bugzilla.mozilla.org/show_bug.cgi?id=246213

here the background of the image is missing, and if you open a box to select
product or version or something, background is wrong.

checkins in regression timespan:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=20040608+08%3A00&maxdate=20040609+11%3A00&cvsroot=%2Fcvsroot

Maybe Bug 241161 [quirks] empty TABLE should hide
Assignee: general → nobody
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout: Tables
Ever confirmed: true
QA Contact: general → core.layout.tables
I somehow doubt the regression window especially, that a layout error will not
occure with ff but mozilla they share the same gecko ( at least if branch
builds arent used for comparison). And then all over sudden vanishes on ff.
excite.com is made of javascript, so I didn´t look too much.
I assume the small logo is in a wide table, with black background missing.
The fonts are black, instead of coloured, no coloured or black backgrounds are
seen on the page.
Attached image Bugzilla Bug 246213 — 
Screen resolution 800x600, Win98
The mozilla logo is 600 px wide, and to the right should be black background,
it is missing here. I opened Priority as an example, the background should be
white,
the highlited entry dark blue, here it is not.
(In reply to comment #3)
> Created an attachment (id=150661)
> are we talking about the green quotes on the right???
> 
> I somehow doubt the regression window especially, that a layout error will not
> occure with ff but mozilla they share the same gecko ( at least if branch
> builds arent used for comparison). And then all over sudden vanishes on ff.

I tested this more than twice. First were made in bug 246205.
Today I wanted to be sure, so I repeated the tests on two computers:
Celeron 333, Win98, 96 MB RAM, 8 MB noname graficscard SiS6328
Athlon XP1600, Win98SE, 512 MB RAM, nVidia nForce integrated Video.
Both screen resolution 800x600, default (classic) theme, no themes installed,
I sometimes have extensions LiveHTTPheaders, NukeAnything, LeoDict and
InspectThisPage installed.
I used zip builds, my default Firefox profile, pretty unused, and multiply
changed between working and regressed firefoxes.
I used zip Builds, besides a normal exe, used my normal Mozilla profile, and
before answering, did a third test: mozilla unzipped in new folder (always), but
created a new profile, right at first start, so this mozilla never started with
used a used profile. Profile unchanged, and made screenshots. One is attached,
the other was made earlier.

I´m also very curious how Firefox got fixed, but not mozilla.
All browsers are official mozilla nightlies, downloaded from mozilla.org.
Bernd, you can use my mail address if you got more text than you want to post here. 
I can attach a small testcase made from Tinderbox and a screenshot, or
screenshots for the testcases from the other bug.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040613 Firefox/0.8.0+

In firefox-trunk 2004-06-13-win32.zip (official), colors still do not work 
as indicated in CSS, body element, etc. of the web-page on Win98SE. 
The screen resolution is 1024x768 px (true color 32bit).
Attached image ScreenShot (png file) — 
ScreenShot (png file) for http://www.mozilla.org/ browsed by
Firefox (trunk 2004-06-13-09 win32.zip) on Win98SE
(Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040613
Firefox/0.8.0+).
www.mozilla.org is not in quirks mode.

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsTableFrame.cpp&branch=&root=/cvsroot&subdir=mozilla/layout/html/table/src&command=DIFF_FRAMESET&rev1=3.570&rev2=3.571
 
       (tableSpecifiedHeight > 0) &&    
        eCompatibility_NavQuirks != GetPresContext()->CompatibilityMode())
        // empty tables should not have a size in quirks mode
I simply doubt that the analysis pointing toward that patch is correct.        
         

I never use zip builds.
Attached file testcase — 
small testcase using start of mozilla start page
from Win98 properties: Firefox 1.8a2: 2004061113
zip install used in the comments before
from Win98 properties: Firefox 1.8a2: 2004061308
fresh download from Firefox (trunk 2004-06-13-09 win32.zip)
(In reply to comment #9)
> www.mozilla.org is not in quirks mode.

> I simply doubt that the analysis pointing toward that patch is correct.        

Sorry, it was a blind shot based on the short regression time span, and the
subject of that bug. After looking at the very short patch i´m in doubt too.

My testcase here is in Standards compliance mode, and includes the table 
shown in Quirks mode in
http://bugzilla.mozilla.org/attachment.cgi?id=150541&action=view

I´m using zips for regression testing, as they are fast installed and deleted.

I was surprised when I saw Firefox  1.8a2: 2004061113 working, and later
Mozillas not. I was even more surprised this morning, that a later Firefox is
regressed again, but 2004061113 still working. Tested using same profile,
2004061113 tested before and after testing Firefox 1.8a2: 2004061308
ScreenShot(png file) of http://www.mozilla.org/developer/ (quirks mode) 
browsed by Firefox (trunk 2004-06-13-09 win32.zip) on Win98SE.
*** Bug 246693 has been marked as a duplicate of this bug. ***
In FirefoxSetup.exe of 2004-06-13-09-trunk, the same bug behavior was observed
on Win98SE.
Is this bug related to 2004-06-08-Checkins to modify the behavior of 
Bug 239914 ?
mozilla/toolkit/xre/nsAppRunner.cpp  or
mozilla/chrome/src/nsChromeRegistry.cpp
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/chrome/src&command=DIFF_FRAMESET&file=nsChromeRegistry.cpp&rev1=1.300&rev2=1.301&root=/cvsroot
or
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/toolkit/xre&command=DIFF_FRAMESET&file=nsAppRunner.cpp&rev1=1.30&rev2=1.31&root=/cvsroot

Does nuking the xul.mfl file in your profile directory help?
*** Bug 246661 has been marked as a duplicate of this bug. ***
Please CHANGE the summary to find this bug easier and avoid further dupes.
Include something like "Background colors and images are not
displayed/rendered/shown; wrong colors for links, ...".

I noticed the following broken things on all pages since the regression:

- background colors and images are not displayed/rendered/shown; 
- background of comboboxes are wrong
- View Source syntax highlighting is broken (only b/w)
- background images are not listed in View Page Info - Media
- wrong colors for links (only default colors are used)

I guess Bug 239914 caused this regression (at least for Win9x, Win NT4). See Bug
239914 comment 0: "When a high contrast theme is being used, Mozilla should
automatically use those colors for the web page. This is the equivalent to "Use
my chosen colors, ignoring the colors and background image specified by the web
page".
> Does nuking the xul.mfl file in your profile directory help?

Does it mean the deleting of XUL.mfl is helpful?
If so, I created new profile, and also tested after the removal of XUL.mfl.
I keep set the config key of browser.display.use_document_colors as "true".

The bug seems to come out in old windows such as Win98, 98SE, NT4.0.
Firefox on Win-XP shows correct colors indicated in CSS, body element, etc. of
web page.
(firefox-20040614-11-trunk-zip).

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040615 Firefox/0.8.0+

Latest trunk firefox on Win98SE showed correct colors indicated in CSS, 
body element, etc. of web page.

-> FIXED?  Users of old-type Windows may test latest trunk. 
If confirm it fixed, please change status to FIXED.
Still no backgrounds and colors with Mozilla trunk build 2004061507 on WinNT4.
Almost all sites look terrible. This bug is serious for NT4 and Win9x users.

Reporter, please change the summary as suggested in comment 20.
(In reply to comment #24)
> Latest trunk firefox on Win98SE showed correct colors indicated in CSS, 
> body element, etc. of web page.
Yeah, for FF it seems to be ok. WFM with latest FF trunk build on WinNT4.
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a2) Gecko/20040615 Firefox/0.8.0+

But not with Seamonkey trunk builds! :-((
The problem is not solved although verified by trunk (2004-06-15-07-trunk) of
Seamonkey in Windows 98SE.
Assignee: nobody → aaronleventhal
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040616 Firefox/0.8.0+

still showing bug. Didn´t check seamonkey.
I deleted XUL.MFL, and had a look at user.js, and about:config, to no avail.
So this bug seems to be still active on Win98 Trunk both Seamonkey and Firefox.

I´m changing bug summary and URL, to enhance the visibility of the bug.
Summary was:  Color missing from stock quote entries.
URL was:      http://www.excite.com
URL: http://www.excite.com → http://www.mozilla.org/products/firefox/
Summary: Color missing from stock quote entries. → background colors and images are not displayed/rendered/shown
*** Bug 246917 has been marked as a duplicate of this bug. ***
Can someone test the following workaround? 
-> In about:config, create a pref called ui.useAccessibilityTheme and set it to
false.
This will tell me if the regression is from my code.

I can understand why my code would fail on WinNT, but not Win98.

Anyone have a debug build that they can test this patch with? I don't have
Win98 or WinNT around.
(In reply to comment #30)
> Can someone test the following workaround? 
> -> In about:config, create a pref called ui.useAccessibilityTheme and set it to
> false.
> This will tell me if the regression is from my code.
> 
> I can understand why my code would fail on WinNT, but not Win98.
> 
user_pref("ui.useAccessibilityTheme", false);
edited into my prefs.js file in thunderbird has no effect (same symptom)
I doubt if the pref is even checked in Tbird.
Which leads me to my next question, why would any change be checked into
the trunk without at least a cursory run through with most operating systems?
Win98 is still not obsolete.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040616

Firefox-2004-06-16-trunk-zip regressed again on Win98SE.
And also I set the boolean value for the key of ui.useAccessibilityTheme 
to false, but it does not work.
(In reply to comment #30)
> Can someone test the following workaround? 
> -> In about:config, create a pref called ui.useAccessibilityTheme and set it to
> false.
Doesn't change the wrong behavior on WinNT4 for me. But if I look at
http://lxr.mozilla.org/seamonkey/search?string=ui.useAccessibilityTheme, I'm not
sure if this pref is used on platforms like WinNT4 and/or Win9x.

> why would any change be checked into
> the trunk without at least a cursory run through with most operating systems?
> Win98 is still not obsolete.
Then use 1.7. These are nightly builds, not even "alpha". Not all engineers have
a machine with every OS - we'd have to have a half-dozen computers.


(In reply to comment #34)
> Doesn't change the wrong behavior on WinNT4 for me. But if I look at
> http://lxr.mozilla.org/seamonkey/search?string=ui.useAccessibilityTheme, I'm not
> sure if this pref is used on platforms like WinNT4 and/or Win9x.

No, it's used, but I made a mistake. It's not a bool pref. It's an int pref.
Now try this: go into about:config and right click on that pref, and "reset".
Then exit Mozilla, restart, create a new integer pref with the same name, and
set it to 0. Then exit Mozilla and restart. The workaround should be effective.
Comment on attachment 150996 [details] [diff] [review]
This fix probably works for NT, but I don't know about Win 98.

We should check the return value of SystemParametersInfo()
Attachment #150996 - Flags: review?(ere)
With the correct pref it works (Mozilla WinNT4)! THANKS. Now I can use/test
trunk builds again.
Integer pref also working on Win98SE and Win98 with Firefox and Mozilla.
Integer pref work fine in Thunderbird trunk builds,
when manually edited into prefs.js
Thanks for the info.
Please clarify whether you consider this problem has been resolved for Win98
users. I still have difficulties with it.
Thanks.


(In reply to comment #41)
> Please clarify whether you consider this problem has been resolved for Win98
> users. I still have difficulties with it.
> Thanks.
> 
> 

There is a workaround but it's not fixed yet -- the patch has review? flagged on it.

It works fine with integer pref on moz, fx, tb trunks.  Thanks a lot!
The bug is still present in build 2004061507 under Windows NT. It was'n in build
2004060308.
(In reply to comment #44)
> The bug is still present in build 2004061507 under Windows NT. It was'n in build
> 2004060308.
Right, the patch isn't checked in yet. Until then you have to use the
workaround, see comment 36.


*** Bug 246475 has been marked as a duplicate of this bug. ***
Re comment 45: That does it, at least for build 2004061507 and Win NT 4.0. Thanks.
*** Bug 247503 has been marked as a duplicate of this bug. ***
I've read comment 36 but still not sure what 'about:config' is. Can someone
please explain this and also the navigation path to get to it (assuming it's a
menu option). Until then, I'm not in a postion to adopt any workaround.
Thanks.
(In reply to comment #49)
> I've read comment 36 but still not sure what 'about:config' is. Can someone
> please explain this and also the navigation path to get to it (assuming it's a
> menu option). Until then, I'm not in a postion to adopt any workaround.
> Thanks.

Type about:config in the url-bar. There you can change the option.
Thanks for info about 'about:config'. I've had a look at this listing and there
is no entry for 'ui.useAccessibilityTheme'. Do I need to create a new entry to
attempt the workaround suggested?
Thanks.
*** Bug 246920 has been marked as a duplicate of this bug. ***
*** Bug 247743 has been marked as a duplicate of this bug. ***
Priority: -- → P1
(In reply to comment #51)

> Do I need to create a new entry to attempt the workaround suggested?

Yes. Creat the pref key of 'ui.useAccessibilityTheme', and then set the
pref int value to '0'.

I see the same thing on BeOS, on a CVS build I made myself yesterday.

Checking with the workaround now.
Workaround from comment #30 works with 2004062008 on win95
Adding the workaround also fixes the image on BeOS. We have our own
nsLookAndFeel.cpp, so this seems a bit weird.

If the original intention was to make users with a High Contrast theme see a
high contrast web by default, surely it would be better just to make the pref
about not allowing websites to use other colours be true by default for these
users, thus allowing the user to override it if they want. At the moment this
pref is useless for people with high contrast themes, as far as I understand.
*** Bug 247931 has been marked as a duplicate of this bug. ***
Attachment #150996 - Attachment description: This fix probably works for NT, but I don't know about Win 98. Needs testing → This fix probably works for NT, but I don't know about Win 98.
*** Bug 247743 has been marked as a duplicate of this bug. ***
*** Bug 248050 has been marked as a duplicate of this bug. ***
*** Bug 248122 has been marked as a duplicate of this bug. ***
Attachment #150996 - Flags: review?(ere) → review?(mkaply)
Comment on attachment 150996 [details] [diff] [review]
This fix probably works for NT, but I don't know about Win 98.

I think I'd rather see this as an if/else to be more readable. Also please put
a comment:

/* Need to check return from SystemParametersInfo since SPI_GETHIGHCONTRAST is
not supported on Windows NT */

Note that the docs say that NT is the only platform it isn't supported on.
Attachment #150996 - Flags: review?(mkaply) → review+
Comment on attachment 150996 [details] [diff] [review]
This fix probably works for NT, but I don't know about Win 98.

Thanks Mike, I'll add those suggestions. Seeking sr=darin.
Attachment #150996 - Flags: superreview?(darin)
Comment on attachment 150996 [details] [diff] [review]
This fix probably works for NT, but I don't know about Win 98.

>Index: nsLookAndFeel.cpp

>+        aMetric = 0;
>+        if (SystemParametersInfo(SPI_GETHIGHCONTRAST, 0, &contrastThemeInfo, 0)) {
>+          aMetric = (contrastThemeInfo.dwFlags & HCF_HIGHCONTRASTON) != 0;
>+        }

Sort of silly to assign aMetric twice.	Use an else clause like so:

	if (SystemParametersInfo(SPI_GETHIGHCONTRAST, 0, &contrastThemeInfo,
0)) {
	  aMetric = (contrastThemeInfo.dwFlags & HCF_HIGHCONTRASTON) != 0;
	} else {
	  aMetric = 0;
	}

sr=darin with that change.
Attachment #150996 - Flags: superreview?(darin) → superreview+
The pref should not be necessary starting with builds on 6/23. I'd like to get
some data points on Win98 and WinNT. If there's a problem on BeOS that's a
complete mystery to me.

Checking in nsLookAndFeel.cpp;
/cvsroot/mozilla/widget/src/windows/nsLookAndFeel.cpp,v  <--  nsLookAndFeel.cpp
new revision: 1.46; previous revision: 1.45
done
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
It's interesting to note that VC6sp5 appears to generate smaller code when the
else clause is used.  In fact, VC6sp5 with /O2 is able to optimize away the jump
in the case where the else clause is explicit.  I would have expected the
compiler to generate the same code in both cases, but I guess it doesn't.  The
optimization is based I think on the fact that the else clause assigns a value
of zero to aMetric.  Anyways, just food for thought.  I'm not sure what other
compilers would do with this.
*** Bug 248292 has been marked as a duplicate of this bug. ***
*** Bug 248387 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040623 Firefox/0.8.0+

Firefox-2004-06-23-09-trunk works fine without integer pref on Win98SE. 
Fix of the bug is verified at least on Win98SE. Thanks!

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a2) Gecko/20040623

Checked out last night's daily build after removing the pref and it all seems
well on NT.
Still broken on BeOS, but I've found the cause.

Back in 2000, all ports LookAndFeel.cpps were changed to return 0 by default (ie
if the metric didn't exist). For some reson BeOS's wasn't changed (I think it
was in the main tree by then, but maybe not), and still returns -1.

I've opened another bug for that, with a simple patch.

See http://bugzilla.mozilla.org/show_bug.cgi?id=248603
Flags: blocking1.8a2+
(In reply to comment #66)
>It's interesting to note that VC6sp5 appears to generate smaller code when the
>else clause is used.  In fact, VC6sp5 with /O2 is able to optimize away the jump
>in the case where the else clause is explicit.  I would have expected the
>compiler to generate the same code in both cases, but I guess it doesn't.
Perhaps it optimizes the second code to
aMetric = SystemParametersInfo(SPI_GETHIGHCONTRAST, 0, &contrastThemeInfo, 0) &&
          (contrastThemeInfo.dwFlags & HCF_HIGHCONTRASTON) != 0;
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: