PNG Transparency is messed up




17 years ago
17 years ago


(Reporter: James Lariviere, Assigned: Stuart Parmenter)


({qawanted, regression})

Windows XP
qawanted, regression

Firefox Tracking Flags

(Not tracked)




(5 attachments)



17 years ago
PNG Transparency is messed up.


Open a page with a semi-transparent png file and rendering results include: half
rendering or no rendering at all for WinXP or Linux for quite some time.


Goto url.
Look at the sections.

Actual Rendering:
Some of the png's are rendered correctly in one section while partial or no
rendering in other sections.

I'll post a screenshot if not clear.

Expected Results:
The all the selected divs should have consistent semi-transparency.

Comment 1

17 years ago
Created attachment 69534 [details]

Here is the screenshot.

I suggest also to select a alternate stylesheets, either by the Mozilla's menu
or click on the list on the page.  You can see that even when a new stylesheet
(alternate) is selected and the page is redrawn, mozilla does not render this
correctly in linux or windows.

Comment 2

17 years ago
either bug 125484 or bug 125629 I think ...

For me linux cvs yesterday, the right box DOES have it, the left box
doesn't. selecting some text shows more of it.
Keywords: qawanted

Comment 3

17 years ago
Created attachment 76913 [details]
non-transparent png for testcase

Comment 4

17 years ago
Created attachment 76914 [details]
transparent png for testcase

Comment 5

17 years ago
Created attachment 76917 [details]
Testcase 1

When using this test case, do not click anywhere until the background image has

The testcase contains two DIVs, one after the other. They are pretty much
identical, both have a 1px border (red for the first one, green for the second)
and have the background-image set (using css) to the same alpha transparent

Expected behaviour (as seen in IE): The background image is wrapped
horizontally in both DIVs, but is cut off vertically because of the size of the
DIV. The DIVs look identical apart from the border colour and text.

Actual behaviour: The background image is shown in the first DIV and horizontal
wrapping is working correctly. However, the image is not cut off vertially. If
I increase the font size so that the first DIV can fit more than one of the
images in vertically, then the bottom copy of the image is not cropped.

Initially the second DIV does not show a background. However, if you highlight
the text and then click off, the correct background is drawn under the
previously highlighted area (this may be a lucky coincidence).

Also worth noting, on initial page loading the PNG is correctly aligned in the
first DIV. If you minimize and restore the window, then the PNG is drawn from
the top of the page (but you can only see the section inside the DIV). Equally,
dragging other windows over the DIVs produces the same effects as seen in bug

I will post some more test cases in the morning. I think this bug is closely
related to 121230 but is not a duplicate.

Comment 6

17 years ago
Created attachment 76963 [details]
Testcase 2

Similar testcase here. The top div doesn't have a background, the bottom has
the same, alpha transparent background as before. Spacing has been added at the
bottom to enable scrolling.

Drawing on initial loading is correct. When the entire window is hidden and
then reshown, the background PNG is drawn from the top of the window. If you
don't scroll down this will mean that you don't see the png being drawn at all
- only the bits which fall inside the area of the div are drawn.

After working through all this I realised this is more like bug 121230 that the
problem described above. I'll try to reproduce the problem above.

Comment 7

17 years ago
OK, I figured this one out finally (sorry for the spam).

In the url for this bug and in testcase 2, the background image in question is
being drawn to the correct height but at the top of the window.

In testcase 2, this can only be seen by reloading the page.

However, on the url, the div which is meant to have the background acts like a
window to that background. When it is over the area where mozilla is drawing the
background, it will show the background, when it isn't the background will be
hidden. Think of it like those magic pens that kids get - you write in invisible
ink and then when you colour over it in the correct ink it will show up.

I am marking this bug depends on 121230, because I suspect fixing that bug will
fix this bug too (and the testcases also exhibt 121230).

Issues NOT addressed by 121230 but addressed by this bug are:
 * The drawing of a background outside of the area required. (testcase 1)
 * The 'magic window' effect
Depends on: 121230


17 years ago
No longer depends on: 121230

Comment 8

17 years ago
Even though bug 121230 was fixed you can still see that transparency is messed
up -- see Screenshot (attachment 69534 [details]).  In the screenshot, I've explained
where its messed up.  I know that IE doesn't support this but atleast it doesn't
render the png's currupted like mozilla does.

This is a regression.
Keywords: regression

Comment 9

17 years ago
this could be a dupe of 123511

Comment 10

17 years ago
no its not

Comment 11

17 years ago
Err sorry... I think this is actually two bugs.  The URL seems to have bug
125629, but the testcases have bug 123511.  Dupe this against one of them...

Comment 12

17 years ago
Marking dupe.

Does anyone know the cause of this regression?

*** This bug has been marked as a duplicate of 125629 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.