Closed Bug 91034 Opened 23 years ago Closed 23 years ago

css background image doesn't display correctly

Categories

(Core :: Graphics: ImageLib, defect, P2)

Product:
Core
Component:
Graphics: ImageLib
Platform:
PowerPC
Mac System 8.6
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: august.mayer, Assigned: pierre)

References

(
URL
)

Details

(Keywords: html4, platform-parity, regression)

Attachments

(10 files)

ie rendering
43.59 KB, image/png
Details
mozilla rendering
41.52 KB, image/png
Details
mozilla 2001-07-16-08 testcase
21.27 KB, image/png
Details
testcase with strict DTD
529 bytes, text/html
Details
testcase without strict DTD
437 bytes, text/html
Details
very simple testcase
590 bytes, text/html
Details
very simple and slightly better testcase
716 bytes, text/html
Details
testcase with Body
961 bytes, text/html
Details
testcase with DIVs
451 bytes, text/html
Details
background color in cellspacing
338 bytes, text/html
Details 
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 <bernd.mielke@snafu.de> 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
Depends on: 46268
Keywords: html4, regression
Works fine on Windows 98 with nightly build id=2001070708
Attached image ie rendering — 

    
    

    
  

      
      
      
      

        Attached image
          
        mozilla rendering
        — 
      

    


  

    
    

    
  
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.

    
  
Blocks: 4510

    
    

    
  
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
Keywords: pp
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

    
  
Blocks: 91786

    
    

    
  
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?


    
    

    
  

      
      
      
      

        Attached file
          
        very simple testcase
        — 
      

    


  

    
    

    
  
*** 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.

Keywords: mostfreq, 
          
            nsBranch

    
    

    
  
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. ***

    
    

    
  
The bug is reduced to this simple definition: the background-image doesn't show 
unless there is a background-color.  It is true for any element.  I did not find 
the checkin that caused the regression yet but apparently, it is not one of those 
that I first suspected (bug 46268 and bug 87229).


    
    

    
  

      
      
      
      

        Attached file
          
        testcase with Body
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        testcase with DIVs
        — 
      

    


  

    
  
No longer depends on: 46268

    
    

    
  
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.
Blocks: 93662

    
    

    
  
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.
URL: http://amayer.n3.net → http://www.apple.com

    
    

    
  
*** 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. ***
Blocks: 94272

    
  
Blocks: 93874

    
    

    
  
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

URL: http://www.apple.com → http://www.blizzard.com/
Severity: major → normal
Keywords: qawanted
Priority: P1 → P2
Target Milestone: mozilla0.9.4 → mozilla1.0

    
    

    
  
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: 23 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
Keywords: qawanted

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: