[BACKGROUND]Table cell with blank GIF as background displays as black

VERIFIED WORKSFORME

Status

()

Product:
Core
Component:
ImageLib
Type:
defect
Importance:
P3
normal
Status:
VERIFIED WORKSFORME
Opened:
20 years ago
Updated:
11 years ago

People

(Reporter: cpratt, Assigned: dcone)

Tracking

Version:
Trunk
Points:
---
Duplicates:
18657, 18759, 21098, 22643, 23031, 23489, 24079, 25682, 32602

Firefox Tracking Flags

(Not tracked)

Details

(
URL
)

Attachments

(3 attachments)

Test case (HTML file)
980 bytes, text/html
Details
empty.gif (GIF file used with test case)
810 bytes, image/gif
Details
screenshots; each reveal of moz window yields diff. colours
28.46 KB, image/gif
Details 
Build ID: 1999101109
Platform: Windows NT

To reproduce: Load the attached test case. The empty.gif image used as the
background for the table cell displays as black for some reason.

This is a problem as it makes mirablis.com look bad; that's on our smoketest
list.
Offhand, I'd say this is a good catch. Probably belongs under Compositor, but I'd
like to defer to Pam Nunn to decide.
Status: NEW → ASSIGNED
Target Milestone: M12
Oddly enough, using the 1999101208 build under NT, the actual site at
mirabilis.com now displays correctly, but the test case at schist/icq is still
not displaying correctly.
cp:
Is schist a local machine? I'm getting nada trying to
access it.
-p
Target Milestone: M12 → M13
Assignee: pnunn → dcone
URL: http://schist/icq http://www.mirabili...
Status: ASSIGNED → NEW
Whiteboard: jazz/users/pnunn/publish/badtable.html
old test urls:
http://schist/icq http://www.mirabilis.com

I've got a very simple demo of the problem.
I've put it as the test url.
The image displays in a table background fine
as long as it is not tiled in particular way.
It seems solely dependent on the size of the area
of tiling.

I'm reassigning to dcone since I know he
has worked on the tiling code. This may well be a duplicate bug.
-p
URL: http://jazz/users/pnunn/publish/badta...
Whiteboard: jazz/users/pnunn/publish/badtable.html
doh.
Put the url in the url field, not the status field.
doh.
-p
Status: NEW → ASSIGNED
Target Milestone: M13 → M14
*** Bug 22643 has been marked as a duplicate of this bug. ***
*** Bug 18759 has been marked as a duplicate of this bug. ***
Testcase from bug #18759
  http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3981
 which notes "It seems to be working (in Mozilla build 2000010308)
 if TD width<364" for that particular configuration

Note also that bug #18786 and bug #20165 were marked as DUPL of bug #18759
*** Bug 21098 has been marked as a duplicate of this bug. ***
Testcase from bug #21098
 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3924

Note also that bug #22715 was marked as DUPL of bug #21098

Finally, see also bug #18162 which is for the same painting issue, but uses
<TABLE BACKGROUND> instead of <TD BACKGROUND>
*** Bug 23489 has been marked as a duplicate of this bug. ***
*** Bug 23031 has been marked as a duplicate of this bug. ***
*** Bug 24079 has been marked as a duplicate of this bug. ***
Summary: Table cell with blank GIF as background displays as black → [BACKGROUND]Table cell with blank GIF as background displays as black
Background images with transparency can not use general speedup for backgrounds.
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
This bug looks vaguely fixed using the 2.11.00 & 2.10.00 builds on Mac OS, Win32 
& Linux; e.g. behavior is equivalent to IE/Navigator.

I've went through a handful of the many duplicates of this bug, and they all look 
okay, too.

---

Chris & John, please don't hesitate to also give this a poke if you'd like to be 
sure. (Especially since I don't recall what the bug originally looked like when 
manifested. ;)
Status: RESOLVED → VERIFIED
Bummer ... sorry ... there still appears to be a problem (at least with
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3924 from bug
#21098. I'll attach three shots of the amazing technicolor effects
that are generated by ALT-TABbing Nav4.x over top of the mozilla
window and then revealing mozilla again.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
This was with 2000-02-10-14 win95 (and possibly this is platform-specific but
I can't test other platforms. Yet.)
You rock.

That said, using the test case in question, I can't reproduce the problem, but I 
note note display inconsistencies:
	* 2000-02-11-12 Mac OS: works fine (displays equivalent to IE) 
	* 2000-02-10-08 NT 4.0 SP5: entire background of table containing "foo bar 
baz" is black
	* 2000-02-10-08 Linux: a red line of pixels draws through the "Try resizing 
this window..." text.

What is the problem exactly.. is there a test case?
I see the example.. but it does not explain how to reproduce this.  All my test 
cases work fine.. so I am gonna need yours.. and what screen depth you are 
using, etc.  From the description it almost sounds like you are running 8 bit 
mode.. which currently has a palette problem.. and is logged as another bug.
The test case for the recent screenshot is (originally from bug #21098):
  http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3924 

The steps to reproduce are simply to load the above URL and use
ALT-TAB to hide the mozilla window and then reveal it again. Each time
(after the initial load), I get a different (incorrect) display of
colors for the TD BACKGROUND. (However, as elig noted, he could not
reproduce this exactly, but there were some other anomalies with this
test case on winNT, mac and linux [although I don't quite see how his
description of the linux anomaly is possible ?? :-)]).

Perhaps there is something unusual about the particular GIF used
(http://www.emt.ee/est/html3/gif/punanetriip.gif) but the testcase
displays as intended using Nav4.7 on win95.

I am running win95 (4.00.950 B) on a Thinkpad laptop (16 bit -- LCD display
-- Cyber9320 PCI display). The driver is XGIW95A.DRV (v1.00 Trident
Microsystems). Graphics Hardware Acceleration is set to Full (although I set
this to None, rebooted, and could still reproduce).

I haven't reviewed all the other testcases for the duplicates of the TD
BACKGROUND problem, but will do so now. Let me know what other information
you need.
I can't review http://jazz/users/pnunn/publish/badtable.html (of course).

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3981 I can't
reproduce and the original URL for bug #18759, http://www.valinux.com/
has changed it's layout.

I could get unusual TD BACKGROUND painting bugs for:
 o http://bugzilla.mozilla.org/showattachment.cgi?attach_id=2081
    (cpratt, this bug)
 o http://www.acppa.org/ the original URL for bug #23031
 o http://w1.836.telia.com/~u83603822/mozillabug/bug1.htm the original
    URL for bug #24079
 o http://stantoncollegeprep.org/title.html the original URL for bug #23489
 o http://bugzilla.mozilla.org/showattachment.cgi?attach_id=3867 the testcase 
   for bug #22715

In all cases *except* the last one, the initial paint of the page is
OK. However, a scroll-down or a hide/reveal of the window will cause a
change in color/pattern for the TD BACKGROUND.

This may be specific to 16 bit display, or my display hardware (although 
this is a vanilla configuration for (a slightly older) IBM Thinkpad.)
Target Milestone: M14 → M15
*** Bug 18657 has been marked as a duplicate of this bug. ***
*** Bug 25682 has been marked as a duplicate of this bug. ***
*** Bug 32602 has been marked as a duplicate of this bug. ***
In Bug 32602 (a dupe) I've linked a test page for this that I hacked out of my 
404 error, here's the link <a 
href="http://www.griffjon.com/errors/404-2.html">http://www.griffjon.com/errors/
404-2.html</a><br>
A Description of the page is:
<ul>
<li>Incredibly annoying and processor-intensive scrolling background, but it 
helps display the transparency issues
<li>Green griffon logo in top-left with a semi-transparent blue 'fill' (the 
background should be visible through it with a blue tint)
<li> right-aligned table at top right of page with tiled blue semi-transparent 
gif (tile.gif)
<li>Centered table with yellow 'border' and tile fill
<li>Within this table, a semi-transparent picture of a woman's head and 
shoulders(NOT overlayed on top of the blue semi-transparent)
</ul>
Furthermore, all the semi-transparency graphics are hacked by a checkerboard of 
pixels from the original and transparent pixels.

www.x42.com/koolefant has a discussion on the classic netscape v ie differences 
in .gif rendering.  By interlacing two images the way I've interlaced an image 
and transparencies, they found thaty netscape will render one and ie the other.
Target Milestone: M15 → M16
WORKSFORME in 2000-04-16. Could anyone still seeing this please reopen?

Gerv
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
Gerv-- It's working for me as well! Kick ass; I believe this is the first 
browser where all my pages using that transparency trick work! congrats and 
props to whoever fixed it.

well judging by the dups here, this one is still active on Windows:
see bug 36869, bug 37589, bug 42285
Keywords: verifyme
Verified on all platforms. The page displays the same way with IE, Nav 4.74 and 
Seamonkey.
Status: RESOLVED → VERIFIED
Now also reported in bug 45744 on NT with build ID 2000-071708
I tagged that a dup of bug 37589 which now has 4 dups.
They should really be all dups of this one however, since earlyer dups of the
exact same site (slashdot) have been dup'ed here.
This is a "mostfreq" in disguise.
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.