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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: robert.a.lindley, Assigned: aaronlev)
References
()
Details
Attachments
(9 files)
23.47 KB,
image/png
|
Details | |
16.12 KB,
image/png
|
Details | |
39.76 KB,
image/png
|
Details | |
17.14 KB,
image/png
|
Details | |
1.63 KB,
text/html
|
Details | |
9.51 KB,
image/png
|
Details | |
9.39 KB,
image/png
|
Details | |
14.79 KB,
image/png
|
Details | |
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.
Comment 2•20 years ago
|
||
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.
Comment 4•20 years ago
|
||
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.
Comment 5•20 years ago
|
||
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.
Comment 6•20 years ago
|
||
(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).
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.
Comment 10•20 years ago
|
||
small testcase using start of mozilla start page
Comment 11•20 years ago
|
||
from Win98 properties: Firefox 1.8a2: 2004061113 zip install used in the comments before
Comment 12•20 years ago
|
||
from Win98 properties: Firefox 1.8a2: 2004061308 fresh download from Firefox (trunk 2004-06-13-09 win32.zip)
Comment 13•20 years ago
|
||
(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
Comment 14•20 years ago
|
||
ScreenShot(png file) of http://www.mozilla.org/developer/ (quirks mode) browsed by Firefox (trunk 2004-06-13-09 win32.zip) on Win98SE.
Comment 15•20 years ago
|
||
*** Bug 246693 has been marked as a duplicate of this bug. ***
Comment 16•20 years ago
|
||
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
Comment 17•20 years ago
|
||
In comment #16, some checkins were not listed. All the lists are; http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=aaronleventhal%25moonset.net&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-06-08+07%3A00%3A00&maxdate=2004-06-09+00%3A00%3A00&cvsroot=%2Fcvsroot
Comment 18•20 years ago
|
||
Does nuking the xul.mfl file in your profile directory help?
Comment 19•20 years ago
|
||
*** Bug 246661 has been marked as a duplicate of this bug. ***
Comment 20•20 years ago
|
||
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)
Comment 21•20 years ago
|
||
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".
Comment 22•20 years ago
|
||
> 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.
Comment 23•20 years ago
|
||
Firefox on Win-XP shows correct colors indicated in CSS, body element, etc. of web page. (firefox-20040614-11-trunk-zip).
Comment 24•20 years ago
|
||
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.
Comment 25•20 years ago
|
||
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.
Comment 26•20 years ago
|
||
(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! :-((
Comment 27•20 years ago
|
||
The problem is not solved although verified by trunk (2004-06-15-07-trunk) of Seamonkey in Windows 98SE.
Assignee | ||
Updated•20 years ago
|
Assignee: nobody → aaronleventhal
Comment 28•20 years ago
|
||
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
Summary: Color missing from stock quote entries. → background colors and images are not displayed/rendered/shown
Comment 29•20 years ago
|
||
*** Bug 246917 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 30•20 years ago
|
||
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.
Assignee | ||
Comment 31•20 years ago
|
||
Anyone have a debug build that they can test this patch with? I don't have Win98 or WinNT around.
Comment 32•20 years ago
|
||
(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.
Comment 33•20 years ago
|
||
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.
Comment 34•20 years ago
|
||
(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.
Assignee | ||
Comment 35•20 years ago
|
||
> 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.
Assignee | ||
Comment 36•20 years ago
|
||
(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.
Assignee | ||
Comment 37•20 years ago
|
||
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)
Comment 38•20 years ago
|
||
With the correct pref it works (Mozilla WinNT4)! THANKS. Now I can use/test trunk builds again.
Comment 39•20 years ago
|
||
Integer pref also working on Win98SE and Win98 with Firefox and Mozilla.
Comment 40•20 years ago
|
||
Integer pref work fine in Thunderbird trunk builds, when manually edited into prefs.js Thanks for the info.
Comment 41•20 years ago
|
||
Please clarify whether you consider this problem has been resolved for Win98 users. I still have difficulties with it. Thanks.
Assignee | ||
Comment 42•20 years ago
|
||
(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.
Comment 43•20 years ago
|
||
It works fine with integer pref on moz, fx, tb trunks. Thanks a lot!
Comment 44•20 years ago
|
||
The bug is still present in build 2004061507 under Windows NT. It was'n in build 2004060308.
Comment 45•20 years ago
|
||
(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.
Comment 46•20 years ago
|
||
*** Bug 246475 has been marked as a duplicate of this bug. ***
Comment 47•20 years ago
|
||
Re comment 45: That does it, at least for build 2004061507 and Win NT 4.0. Thanks.
Comment 48•20 years ago
|
||
*** Bug 247503 has been marked as a duplicate of this bug. ***
Comment 49•20 years ago
|
||
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.
Comment 50•20 years ago
|
||
(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.
Comment 51•20 years ago
|
||
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. ***
Flags: blocking1.8a2+
Comment 53•20 years ago
|
||
*** Bug 247743 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•20 years ago
|
Priority: -- → P1
Comment 54•20 years ago
|
||
(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'.
Updated•20 years ago
|
Comment 55•20 years ago
|
||
I see the same thing on BeOS, on a CVS build I made myself yesterday. Checking with the workaround now.
Comment 56•20 years ago
|
||
Workaround from comment #30 works with 2004062008 on win95
Comment 57•20 years ago
|
||
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.
Comment 58•20 years ago
|
||
*** Bug 247931 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•20 years ago
|
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.
Comment 59•20 years ago
|
||
*** Bug 247743 has been marked as a duplicate of this bug. ***
Comment 60•20 years ago
|
||
*** Bug 248050 has been marked as a duplicate of this bug. ***
Comment 61•20 years ago
|
||
*** Bug 248122 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•20 years ago
|
Attachment #150996 -
Flags: review?(ere) → review?(mkaply)
Comment 62•20 years ago
|
||
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+
Assignee | ||
Comment 63•20 years ago
|
||
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 64•20 years ago
|
||
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+
Assignee | ||
Comment 65•20 years ago
|
||
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
Comment 66•20 years ago
|
||
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.
Comment 67•20 years ago
|
||
*** Bug 248292 has been marked as a duplicate of this bug. ***
Comment 68•20 years ago
|
||
*** Bug 248387 has been marked as a duplicate of this bug. ***
Comment 69•20 years ago
|
||
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!
Comment 70•20 years ago
|
||
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.
Comment 71•20 years ago
|
||
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
Updated•20 years ago
|
Flags: blocking1.8a2+
Comment 72•19 years ago
|
||
(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.
Description
•