Mac System 8.6
43.59 KB, image/png
41.52 KB, image/png
21.27 KB, image/png
529 bytes, text/html
437 bytes, text/html
590 bytes, text/html
716 bytes, text/html
961 bytes, text/html
451 bytes, text/html
338 bytes, text/html
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.2+) Gecko/20010716 BuildID: 2001071608 The text on the demo page should be on a lighter background bitmap, but it doesn't show up. This worked until Build 2001-06-25. I have specifically tailored the CSS code to work with multiple Browsers. Specifically, it doesn't seem to like a <td style="url(image.jpg);"> tag. Reproducible: Always Steps to Reproduce: 1. Go to http://amayer.n3.net with current Mozilla build. Actual Results: The text is unreadable because the td background image is not displayed. Expected Results: The background of the text should be a lighter background image (also try with other browsers: IE, Opera)
The regression occured between the builds [06/29-14 trunk] and [07/02-08 trunk]. I can reproduce it with different nightly builds but not with a recent debug build. Still, the culprit seems to me the checkin for bug 46268. CCd <firstname.lastname@example.org> who made the fix for 46268. Reassigned to HTMLTables.
Assignee: pierre → karnaze
Status: UNCONFIRMED → NEW
Component: Style System → HTMLTables
Ever confirmed: true
QA Contact: ian → amar
Works fine on Windows 98 with nightly build id=2001070708
sorry but I can't see any difference between attachment 42676 [details] and 42677. WFM win98 2001071704. A valid testcase would be good, or is this one of the infamous Mac only Bugs ?????
August could you check whether the problem is still there if you change the doctype to a strict doctype like <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
doesn't help. also, the page contents exceed the strict model afaik.
thank you August while I can't repro :-(, I believe your screenshots and your last comment makes clear that this is a painting problem in strict mode, that has been made visible by removing the quirk handling for table backgrounds.
Hmmm. Maybe when we start using the new imagelib to display background images (which should be sometime in the next week, hopefully) this will go away? It seems like it's a platform-specific image display problem.
is this bug related to bug 85519? looks pretty much like the same kind of problem. i have made a testcase for the bug and uploaded it there. my "research" has shown that local css backgrounds work just as they used to, but non local css backgrounds are not loaded. it does not matter if the page is local or not, only the url of the background makes the difference.
Since this is platform-specific, assigning to Imagelib owner.
Assignee: karnaze → pavlov
Component: HTMLTables → ImageLib
QA Contact: amar → tpreston
Marking bug 89955 as duplicate but bumping the priorities here because of the problems created there. Bug 89955 lists the following URLs: http://www.resacorp.com/midmean.htm http://www.apple.com/trailers/fox/joy_ride/ http://www.duxcw.com/digest/Reviews/ioboards/adsusbbd.htm and even http://www.apple.com/ http://www.byte.com/ As I wrote under bug 89955, I can reproduce the problem with [07/31-trunk] but not with [07/26-branch]. Surprisingly, I cannot reproduce it with a debug build from a recent trunk.
Priority: -- → P1
Target Milestone: --- → mozilla0.9.3
*** Bug 89955 has been marked as a duplicate of this bug. ***
*** Bug 90996 has been marked as a duplicate of this bug. ***
*** Bug 92675 has been marked as a duplicate of this bug. ***
We have plenty of dups. Reassigned to myself: I found a way to reliably reproduce it with local pages and a debug build. The last bug showed the problem on yet another major site: http://www.businessweek.com/
Assignee: pavlov → pierre
I'm going to attach a testcase that shows the problem with a recent debug build. You may need to make a local copy to reproduce the bug. With a strict DTD header, the image is displayed. Without, the image doesn't show up. CCd karnaze because when the image is not displayed, the table cell has the NS_TABLE_CELL_FRAME_CONTENT_EMPTY bit set, which is bad.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Ignore my latest testcases, they are an illustration of cross-platform table bug 63534 and bug 30692.
*** Bug 85519 has been marked as a duplicate of this bug. ***
This is no longer a Mac-only problem. Bug 85519 which was closed as dup was filed for Sun Solaris.
Note that the change to remove the old imagelib and use the new one for background images and list bullets (which it is not yet used for) should be landing within a week or two (if not within days), so it may not be worth trying to fix this in the current code.
Can someone test this PPC linux or other powerpc platform? Often "mac only" bugs turn out to be endian or signed-char bugs. Also, uninitialized variables often cause worse problems on non-x86 architectures. If this bug is processor- rather than OS-dependent, we should change it to Operating System: All.
In the meanwhile, someone contacted me directly to report a problem on Win2K with the toolbar at the top of http://www.blizzard.com. I checked on Win98: no problem. I checked on the Mac: some pieces of the toolbar are missing and it's a regression that occured between 06/29 and 07/02. Could someone please try on Win2K if the big image is missing on http://www.apple.com/trailers/fox/joy_ride/ ?
The bug can be reproduced in optimized builds only. It is a regression that occured between 06/29 and 07/02 but it doesn't seem to be related to bug 46268. It happens in table cells as well as in DIVs. As mentioned in bug 85519 on [2001-07-18 13:42] on a Sun Solaris machine, the bug can only be reproduced with images stored on a remote server. It makes no difference whether the page itself is stored locally or remotely. I'm going to attach the simplest testcase I found. There is a strict DTD but it doesn't make any difference if it is removed. --- While I do an optimized build, could some people test the "very simple testcase" on other OSes, especially Win2K?
*** Bug 93280 has been marked as a duplicate of this bug. ***
And of course, the bug cannot be reproduced with images that are directly linked through an IMG tag, but only if they are used as background. Is doesn't matter whether the background is specified through a CSS property or an HTML attribute.
*** Bug 92878 has been marked as a duplicate of this bug. ***
*** Bug 93300 has been marked as a duplicate of this bug. ***
Bug 93300 was marked as dup but interestingly enough in the testcase there (http://www.clotho.com/staff/chris/moztest/bckgndtest.html ) some of the background images always show while other ones don't.
Bug 93300 reporter: no, sorry, all of the background images are indeed missing in that test case. The present images in the corners are simple "img" tags.
Everything works fine on Win2k (build id: 2001080203). I compared http://www.blizzard.com/, http://www.businessweek.com/, and http://www.apple.com/trailers/fox/joy_ride/ to MSIE 5--identical rendering. Both "very simple testcases" work as described.
Response to request for ppc linux confirm: On PPC Linux (Yellow Dog 2.0) with Mozilla 2001071922, the background tag renders *correctly*, so it is not an endian issue but a platform issue.
this appeared between 6/29 and 7/2 trunk builds. it doesn't happen on the branch (from bug 93280). adding mostfreq keyword as well.
I checked all the bugs filed since 06/29 with "img | image | back | bg" in the summary line and closed some duplicates. So far, the problem was reported on the Mac mainly but also some flavors of unix (sun solaris twice, I think) and Win2k (but not consistently on Win2k as verified by fantasai). Starting an optimized build now...
*** Bug 91786 has been marked as a duplicate of this bug. ***
Is this a regression from the ruletree landing of 6/1, or did it work after 6/1?
per comments made in a dupe bug, this appeared between 6/29 and 7/2
Someone should see if this is still a problem on pav's branch, which (according to comments on bug 78690) should be landing next week.
Hyatt: I think that all the testcases here and all the duplicate bugs have been verified to be a regression that occured between 06/29 and 07/02. It is not a rule tree problem, or not directly should I say. My prime suspects were originally bug 46268 ("quirks: bgcolor does not fill entire table") and bug 87229 ("should nsRuleNode be using jump tables instead of switch statements?"). The former was cleared fairly quickly because the present bug is not related just to tables and quirks mode. The latter is more or less cleared because I could still see the problem after I backed out these changes from my local tree (thanks to waterson's cvs wizardry). I still don't know why it is platform-dependent... maybe a non-initialized variable. I hope it's not some random write somewhere.
This behavior was not evident to me on my Mac/2001071903 build, but was on 0731, 0801, and on 0.9.3 builds.
Greg: if I'm correct the 2001-07-19-03 build was a 0.9.2 build. The trunk bits were released at 08:00 with a respin at 13:00. The bug is not on the 0.9.2 branch, just on the trunk.
Alex Dent and Pierre Saslawsky are right on about this. When the CSS "background-image" value results in a local filesystem URL, it loads. When it results in an HTTP or FTP URL, it does not load unless you specify a background-color with a valid value other than 'transparent' and 'inherit'.
*** Bug 93515 has been marked as a duplicate of this bug. ***
This should be at least MAJOR.
Severity: normal → major
*** Bug 93594 has been marked as a duplicate of this bug. ***
This is also visible in the new toolbar being used by http://home.netscape.com/ One icon, an IMG in a TD, is visible (Mail), but the rest, which are a TD BACKGROUND, are not visible. This is only on the Mac, and to repeat, does not appear in the branch builds, only trunk.
Apple's site uses background images in their navigation tabs at the top of page. On the far left and right side of tabs should be a background image but now is a white gap. http://www.apple.com/
Hitting me too at http://pixel.recoil.org/ on Mac OS 9 0.9.3 doesn't display the backround to the Lord Pixel heading, June builds did. (do a Select-All to highlight the text to see this). Interestingly, confirm the same page works OK when loading from a local disk, but not from an HTTP server.
18 years ago
I changed the URL in the bug header to apple.com, as I have modified my homepage (http://amayer.n3.net) to use the workaround of additionally setting a background-color.
*** Bug 93555 has been marked as a duplicate of this bug. ***
*** Bug 93874 has been marked as a duplicate of this bug. ***
*** Bug 93913 has been marked as a duplicate of this bug. ***
Not sure if this is already known or not but transparent background images do rendered in the latest carbon (Mac OS X) trunk build (2001-08-07-05). http://mozilla.org/quality/browser/standards/html/body_bgcolor_transparent.html
petersen: the page above renders properly because a bgColor is specified.
*** Bug 94338 has been marked as a duplicate of this bug. ***
18 years ago
This bug is fixed in experimental builds from pavlov's branch (bug 78690, Remove the old imagelib). Added a dependency on that bug. This branch is expected to land soon. Yay! The 08/08/01 Mac build from ftp://ftp.mozilla.org/pub/mozilla/nightly/experimental/NOIMG_20010801_BRANCH/ renders all testcases correctly, including http://www.apple.com/ and others.
Depends on: 78690
I tried your experimental build and it didn't fix problem on http://www.businessweek.com/ (Bug 92675) and http://www.clsc-mercier-est-anjou.qc.ca/ 2 web sites who works just great in Mozilla 0.9.2 Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.2) Gecko/20010629 otherwise seems great.
depending on the speed of your link, there is a problem in the experimental builds.. i've checked in a fix on the branch, although I doubt there will be new test builds before I land tomorrow.
I will attach a simple testcase with bgcolor and cell spacing. As you will see the background color is displayed IN the space BETWEEN the 2 cells in the Brubeck experimental build and Mozilla 0.9.3+ even if cellspacing is set to 5. WFM in Moz 0.9.2 / NS4.78. I saw this bug and the background image bug for the first time exactly in the same build. But the Brubeck patch doesn't seem to fix the "background color in cellspacing" bug who in my mind is probably related.
the experimental build fixes the problem for me, very nice. it just looks a little ugly before the image is loaded, because this area is white and not transparent then. this can be fixed later. bug 92675 is not the same, there are no background images. and that canadian site has some strange scripting going on, which maybe doesn't work with mozilla, or it is the same problem as with businessweek.com.
Benjamin -- The table background painting behavior is the fix for bug 46268. As Pierre said, the change is not related to this bug--and from what I know about the fix, I have every inclination to believe that.
Fixed on the trunk after landing for bug 78690.
The landing fixed most of the problems but I'm still seeing the following things. As Alex wrote on [2001-08-08 20:48], these could be un-dup'ed, or filed as separate bugs. http://www.blizzard.com The black background has big patches of white. The large image is missing. bug 92675 / http://www.businessweek.com/ The page never stops loading. The images don't display. http://www.clsc-mercier-est-anjou.qc.ca/ The items in the list on the right hand side don't have a blue background.
http://www.blizzard.com It is a regression from 06/29. The rendering is worse after landing bug 78690. Before the landing, the large image and some small chunks of the toolbar were missing. After the landing, the images are still missing and we have large patches of white instead of a black background. http://www.clsc-mercier-est-anjou.qc.ca/ It is a regression from 06/29. The rendering doesn't change after landing bug 78690. http://www.businessweek.com/ It is NOT a regression from 06/29. It could be a dup of bug 82720. I reopened it (bug 92675)
Reduced priorities since most problems have been fixed in bug 78690. Marked qawanted to get some help to extract smaller testcases from blizzard.com and anjou.qc.ca
Filed bug 94933 for the specific case for www.clsc-mercier-est-anjou.qc.ca. That involves a '404 Not Found' table background; on mac/linux that makes the table opaque/white, while on win32 it make the table transparent.
Okay, it turns out that the problem with http://www.blizzard.com/ is the same deal as reported in bug 94933. In the HTML for blizzard, there are 53 uses of "<td background=0 ...", which is setting the background image to be 'http://www.blizzard.com/0', which, of course is '404 Not Found'. If you remove those bogus attributes, then the entire document looks fine.
Confirm John observation. Add the missing file to anjou.qc.ca -> Work great. But this behavior should be fix under mac and linux.
the 'missing background image file is white' bug seems to be the same bug that i mentioned on 2001-08-08 20:48, before the background is loaded the area is not transparent, but white; on mac at least. does this belong to this bug? or is this something for bug 78690?
*** Bug 95104 has been marked as a duplicate of this bug. ***
*** Bug 94346 has been marked as a duplicate of this bug. ***
This was mostly fixed by the imageLib landing (bug 78690). The remaining problems are under bug 94933 and bug 92675. Marked fixed. We won't know what created the regression.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
*** Bug 95276 has been marked as a duplicate of this bug. ***
*** Bug 95379 has been marked as a duplicate of this bug. ***
*** Bug 98806 has been marked as a duplicate of this bug. ***
Verified fixed linux build 2001-09-17-05-0.9.4 Verified fixed mac OS X build 2001-09-17-04-0.9.4 Verified fixed w98 build 2001-09-17-05-0.9.4
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.