From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.7+) Gecko/20020119 BuildID: 2002011908 having a fixed DIV with a png background causes hovered links to display the wrong part of the image. see URL for a better 'description'. Reproducible: Always Steps to Reproduce: 1. visit http://frozenfire.dnsalias.net/NEMESiS/testcases/AD-CSS-new/newtest.html 2. hover one of the links. everything's fine, right? 3. ok, now apply the alternative Stylesheet having the same picture as png (View->Use Stylesheet->Enlighten Theme (other)) 4. hover the links again. see the error. (does not really apply to this bug, i'll file another one for this specific bug; you might want to to do those two steps, too: 5. reapply the (View->Use Stylesheet->Enlighten Theme (Default)) default sheet. 6. watch the content text go gray) Actual Results: the background of the links get messed up when using png Expected Results: the background should stay as it is (does this with jpeg) [site accesibility: my server has a dialup connection and sets up it's DNS-name via dyndns.org. so it might happen that you can't reach the server sometimes when i loose my carrier and have to redial (and refresh the dnydns-name) - maybe this should mirrored somewhere more accessible, if someone has the webwwspace (153kb)]

Confirmed. (Build ID: 2002 01 21 03). /jc

Confirming on 2002011503 Win2k.

added a third stylesheet called: (third) [obvious, isn't it?] also referring to a png as background. but i played a litte and found my first png (used in stylesheet other) contains an alpha channel. it does not have any transparency, but it does contain the channel. so this seems to cause the bug, because the (third) stylesheet using the png without alpha channel displays well. there you have it. still mozilla should handle images with alpha correcly, doesn't it? -> changing summary from "png as background causes display errors with :hover links" to "png (containing alpha channel) as background causes display errors with :hover links" btw: anyone to mirror this testcase? (size increased to enormous 265kb)

Reporter: If you can get this to happen on your local machine (rather than over the net), try zipping up all the files involved and making a binary attachment to this bug. Then people who want to play with testing and fixing it can just download the attachment.

this is a ZIP-file containing the testcase demonstrated by the URL. it will work local, too. so you don't have to suck it from the web to test it.

Changing QA Contact

Reassigning to Don

Confirming the bug on win2K too. Changing the OS to all. Changing the priority to P2 to get it on the radar.

this isn't only restricted to hovering the links, it also 'works' if you drag another windows over the place, the png is at.

there seems be a general problems with PNGs containing an alpha channel (not nessesarily transparancy - as you can see from comment 3). i was just reading across bug 83289 mentioning crippled pictures in various places and of variing reproducibility. for example this issue (of this bug) is covered there too (they mention http://www.libpng.org/pub/png/pngs-img-bg.html for example), but is not limited to it. so i'll try and summarize everything i think concerns what i've been seeing and reading. * seems to be a windows only problem (due to comments in bug 83289) but this is to be veryfied. * PNGs containing an alpha channel (transparency) are displayed correctly on loading, but break on scrolling, dragging other windows over it, poping up menus or as mentioned here hovering links. * when rezising windows (and refreshing page otherwise) the images are drawn correctly again. * does not happen with PNGs _not_ containing an alpha channel or JPEGs * problems with <img src="http://www.w3.org/Icons/valid-html401"> CSS/HTML validity images are covered by this bug adjusting summary from "png (containing alpha channel) as background causes display errors with :hover links" to "PNG (containing alpha channel / transparency) causes display errors on scroll or other interaction" also changing URL from "http://frozenfire.dnsalias.net/NEMESiS/testcases/AD-CSS-new/newtest.html" to "http://www.libpng.org/pub/png/pngs-img-bg.html" which demonstrates this problem in a wider scale i suggest to increase the priority of this bug and target and nominate it for 0.9.9 or _at least_ 1.0 especially because of the many sites that should have display problems because they include the Valid HTML or Valid CSS banners from http://www.w3.org/Icons/valid-html401 which show this vulnerability.

oh, i almost forgot: i now believe this to be an ImageLib problem rather than Layout. should this be reassigned and (due to increased sererity imho) re-targeted, please? i believe this to be urgent! (just think about every page showing an valid html/css w3-banner being concerned!)

Daniel Steinberger pointed out that bug 94494 may be related.

due to comment 10 and comment 11 i change this over to component imagelib. as already mentioned, i'd suggest to nominate this for 0.9.9 and at least 1.0 - in my opinion this has at least(!) major severity!

noone seems to read this stuff, so retargetting

don't retarget my bugs. -> FUTURE

to be exact: i didn't retarget YOUR SETTING, since the target was set, _before_ i changed it over to imagelib, as you can see when watching the bug activity. and since it would certainly have been correct to target this one mozilla 1.1 for the layout component, which i filed this bug for, i do not agree to this target for imagelib, which I did change this bug to, after discovering all those things. but yes, it's your bug, and you do what you want. but since it renders mozilla unusable for /me/, I go back and use 0.9.7 or something, when images did work at least. pitty, but yes: such is life, i know. bugzilla will have me informed, when this is fixed.

bug 50464, bug 123266, bug 123511 and bug 124657 seem to be about the same thing. (I don't see this bug on linux, however.)

hm, yeah! those bugs seem similar, though bug 50464 deals with your screen beeing in 8bit color. didn't check this since i don't use that little colors for several years =) but the image corruption at the given URL does fall unter this bug's criterias, too. all the other pages seem to be dupes indeed, with worse investigation on the bug's causes. maybe one should mark them dupes? and yes, my summary in comment 10 already mentions in the first item, that it seems to be a windows only problem. (i can't verify this, since moz won't run on my linux box.) but maybe someone could check this in a mac build? i can't =(

Here's a reduced (4 KB) test case that displays the bug in build 2002020803 on Windows ME. Just unzip the file, open alpha.html, and scroll down and up to see the breakage. PNG images that use binary transparency are _not_ affected.

this testcase enhances the wonderful testcase of Damian Yerrick in two points: i've added a 1bit PNG to show that they're unconcered as mentioned before. but that's not the whole point. the interestning thing is a behavior i just figured out while playing with damian's testcase - 8bit alpha PNGs on a fixed background. what I see and expect you to see also, is: the 8-bit alpha PNG scrolls up to the top of the page, seeming to stay there while you're scrolling further up (to improve visualisation, I've added red borders around the images for the demonstrating stylesheet). Gotta see this yourself. =) with fixed background, the images don't get scrambled, but still are not bahaving right.

*** Bug 123511 has been marked as a duplicate of this bug. ***

*** Bug 124657 has been marked as a duplicate of this bug. ***

merging keywords from bug 123266: mozilla0.9.9, nsbeta1, regression

*** Bug 123266 has been marked as a duplicate of this bug. ***

Let me get this straight... was this a problem before the recent windows imagelib changes that changed the way we handle image storage? Is this bug really OS=ALL or is this windows-only?

oh... amar@netscape.com set OS/Version from Windows XP to All on 2002-02-01 11:57:18 i don't know why.. i can only confirm this on windows. but i've heard, this is NOT os=ALL... haven't heard complaint from the linux/mac guys. bz: can you confirm this is not a bug on linux? than i change it back from ALL to Win32 and: i don't remember when it changed, but it DID work fine some time before.. when did the imagelib change go in? i could recheck, if it depends on it?

WFM linux, cvs yesterday.

I can't reproduce this on any of the listed testcases on Linux... The imagelib stuff I was thinking (bug 104999) went in Feb 8, so it's not the culprit.

WFM Mac build 2022021203

*** Bug 125870 has been marked as a duplicate of this bug. ***

bz: which imagelib changes are you talking about?

From comment 28: "The imagelib stuff I was thinking (bug 104999)"

one thing I've noticed about this bug is that if one scrolls the image to view vertically really really slowly (as close to 1 pixel at a time) one can get an upside down mirror image. Note however that this never happens when I tried scrolling horizontally.

*** Bug 127138 has been marked as a duplicate of this bug. ***

this one really stinks! i had the opportunity to install the latest builds of the lizard on some other machines, namely Win98SE boxes, and there this bug does not occur! what a mess... i thought. my first guess was at some hardware/driver compatibility problem. i even suspected screen resolutions or something. so i wanted to know it and made some more tests. here are the results: 0.9.6/Win2K works 0.9.7/Win2K works 0.9.8/Win2K works 2002022103/Win2K SUCKS 2002022103/WinXP SUCKS 2002022103/Win98 works so this bug seems to be present only on WinNT (5+ ?) maybe someone wants to check some NT4 for this bug. i could NOT reproduce this bug a any Win9x machine i have access to.. [ but this access is limited to one Cyrix-P166+ and a Matrox MGA card running Win98SE and a Celeron-400 with an ATI RagePro also running Win98SE-lite =) ] so my tests only say: this bug is not present on Win98SE again.. maybe someone wants to check.. 95abc/98FE/ME/NT4? so here we are again. now it's time to guess a little where the source for this error may be. the best thing would certainly be if someone hacks into this and finds it out, but this will certainly not me, or the lizard wouldn't display a single image anymore, i guess =) another question arising is this: i filed this bug on 2002-01-22 07:11, branch time for 0.9.8 was 18-Jan-2002 and as seen on 2k (never had it on XP), 0.9.8 hasn't got this bug... what was checked in in this time, that could be the reason for this? (it does not seem to be bz's IMlib bug 104999; their checkin was 01/30/2002 14:17)

It seems there are different bugs collected here. With 0.9.8 on W2K I can't reproduce the bug given in the reduced test case. BUT: I _can_ reproduce the Bug given in the first link of the first posting Furthermore I still can reproduce (0.9.8, W2K) the bug 123511 which is marked as a duplicate of this bug. Maybe this shouldn't be a duplicate. The main problem there is: background png image with transparency. No other conditions as fixed DIVs etc. There is a very minimal test case given with 123511 to reproduce the bug. So either the test case from 123511 should be added to this bug or this bug should be splitted. Timo

Comment #36 From Timo Boehme is verified to be correct: Win98 is not affected when just scolling an 8bit-transparent PNG, but also has the same problem as any other windows when it comes to 8bit-alpha PNGs in the background. [this background issue still does _not_ occur with 1bit-alpha PNGs.] Timo: i will just add your testcase to this bug, since i bet fixing the scrolling issue fixes the other problem, too. you know i widened this bug from about the same thing you also mention to covering the whole thing. i mean, the cause will still be the same for both bugs. but we'll keep an eye on that and reopen your bug, if this guess turns out to be untrue. testcase (also affecting win98) from timos bug 123511: create a html file containing the following code: ---------------------------------------- <html> <body> <table> <tr> <td background="back.png"> TestTestTestTest </td> </tr> </table> </body> </html> ---------------------------------------- save attachment 67883 [details] as "back.png" in the same directory and move an other window over the table. note the image corrution also in win9x. [win9x also is affected by the steps to reproduce in the opening comment]

*** Bug 127356 has been marked as a duplicate of this bug. ***

On NT4 with build 2002030409 I see problems with the original attached test case but not the third. WFM on Linux with build 2002030421. I first came across this problem at http://fantasyfilmleague.com/ where the banner renders incorrectly on scrolling up. Again, fine with the Linux build, but not the NT4 one.

->WFM till someone proves me wrong

No, its still here in Windows (2002030409)

I am still seeing this bug, build 2002022603 on Win2000 I can see this on the XHTML1.0 png at the bottom of http://validator.w3.org/ Use the scrollbar to scroll down, not the mousewheel, as when I used the mousewheel the image came onto the screen in one go.

s/Windows/Windows XP/ s/2002030409/2002030403/ sorry to spam, but in case this gets questioned...

I'm still seeing this with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020305. (specifically the -11 nightly on Windows 2000) As another test case (in quick skim didn't see any other comments about keyboard causing this), I see this when pressing space and backspace in the textarea when voting on MozillaNews. http://www.mozillanews.org/index.php3?vote=1 Type in the field and notice that the MozNews logo in the upper left jumps. Scrolling the page up and down causes a similar breakup. Clicking in the location bar and back to the page seems to clear the problem (probably a repaint event is triggered).

The problem seems to be that, when a part of the image is uncovered, mozilla starts drawing vertically from the bottom. Say that you had a 30px high image, of which the top 5px was showing. If you scrolled down another 5px, this would show rows 21-25 in the 5px that was revealed. Scrolling down another 7px would show rows 14-20 (since 10px are already showing, 30px-10px = 20px). The problem does not occur horizontally. Note that it occurs for both scrolling and if a png is revealed by moving a window partially out of the way. It also occurs if only part of the width of the image is showing (but only in the part that has been uncovered). The bug still occurs when you uncover the whole image at the same time, its just that then it happens to draw it correctly.

My previous comments are true when you are scrolling down a page, but don't seem to be true when you are scrolling up and page. When you are scrolling up, it appears to be drawing the top of the image each time and extra section is required. I hope this helps someone.

this bug definitly _is_ present. summary: it occurs only on the windows platform (not on mac or linux). and only on NT derivates (win2k, winxp). it does not occur on win9x while scrolling. (8bit PNGs in background cause problems there, too) this might lead to more problems when more and more people switch over to winXP (like microsoft wants them to do) and for companies generally running NT or 2k rather than 9x (nsenterprise?). and because gagan@netscape.com marked bug 94494 and bug 83289 nsbeta+, i don't see why this one should not be. the reproduction isse is easily solved by using 2k or XP (NT4?). and as already mentioned, it is reproducable in 9x too, when the PNG is used as a background, as demonstrated by sample code in comment 37. but if you still think this is not important enough for nsbeta1+ ... i won't argue =)

This bug does not just affect the Win NT based systems. WinME is also affected (build 2002030508).

here is another testcase (which is easy to test as it is not a zip file). Steps to repro: 1 scroll page so that only half the image is visible. 2 notice that the image is now a mess 3 click on the image 4 notice it got repainted but is painted wrongly 5 right click on the image 6 click somewhere else on the screen 7 notice a similar effect

Sorry, but the latest test case (attachment 72749 [details]) WFM on both the builds I mentioned in comment 39. Are we dealing with two bugs here? One for backgrounds and one for other images? Is this why Gagan says WFM? Anyway, I have attached a screenshot of the problem in action; a vain attempt to persuade Gagan there's a bug here. It seems to demonstrate the symptoms described in comment 45. I achieved this by scrolling down then scrolling up using the scrollbar buttons, so that the scroll steps were sufficiently small. I don't believe the image in question has an alpha channel; please correct me if I'm wrong.

Broken for me as well Running Windows XP Mozilla: 20020306034 Display: Very, very old video card- "Trident Video Accelerator 9440" Screen resolution: 640x480 Color depth: 16bit Advanced/troubleshooting options Hardware acceleration: full "Enable write combining": checked It probably won't happen on a fast video card. It seems that first blit of the section uncovered sends the topmost section of the png, the next blit shows the chunk below the topmost bit, equal to the size of the blit. Almost like: Start blit = 0 + amount of png currently showing I'll try some more tests...

No, I'm pretty sure this has nothing to do with video card speed (or video cards at all). I see this problem and I have a GeForce 2MX (and my system is Dual Athlon XP 1700+, 1GB DDR 266 ECC RAM).

Look pngmozillastretch/index.html inside the zip for another testcase. Tested on Win2K with mozilla 0.9.8.

*** Bug 130028 has been marked as a duplicate of this bug. ***

*** Bug 115486 has been marked as a duplicate of this bug. ***

Bug partially solved for me on W2K with 0.9.9. Using testcase http://bugzilla.mozilla.org/showattachment.cgi?attach_id=72749 I found the following (new) behaviour of Mozilla: Moving the window right/left across the screen border the picture is correctly displayed if I move it back. But moving the window top/down across the screen border the image is displayed upside down! when moving (line by line) back. So it seems the right/left movement is fixed but top/down has still a (serious) bug.

*** Bug 128179 has been marked as a duplicate of this bug. ***

Testing on Win98 shows this regressed between 0.9.7 and 0.9.8 (at least as far as comment 50 is concerned). Taking a wild stab in the dark, here are the CVS log entries for gfx/src/windows/nsImageWin.cpp during this period: 3.85 / rods@netscape.com / Jan 15 19:16 / Fixes round off error for scaling and fixes to var names / Bug 120072 / r by dcone, sr by attinasi 3.84 / dcone@netscape.com / Jan 9 07:02 / Added support for fast alpha tiling / Bug 98252 / r by kmcclusk, sr by attinasi It could be the 3.84 change; 3.85 is just a tidy up. The changes are mostly to DrawTile. As the alpha-blending code branches for 8-bit I tested at multiple colour depths, but this made no difference. I'm affraid that's the best I could come up with, apologies if it's a red herring. :-/

Umm no, scrolling left and right was never a problem. See comment #33.

Left/right was a problem. See bug 123511 which is marked as a duplicate of this bug. Maybe there are some differences. At least for bug 123511 the repainting behaviour has changed from 0.9.8 to 0.9.9.

Okay, one last thing to add: DrawTile is called at line 3117 of nsCSSRendering.cpp differently on Windows as compared to other platforms.

In that case, I think that maybe the background PNG issue may have been a different issue than the non-background PNG issue, as you (Timo) stated in comment #36. But the other issue (vertical scroll) affects all alpha PNGs.

*** Bug 130966 has been marked as a duplicate of this bug. ***

Having problems with this page too. http://www.stormkeepers.org/stormguard/index2.php?act=main Same bug?

Comment #64 From Ho KS: the main background (http://www.stormkeepers.org/stormguard/images/background11.jpg) is certainly not affected, but there is a PNG (http://www.stormkeepers.org/stormguard/images/graydots.png) which is only 8x8 pixel, and has an 8bit alpha channel. so it fit's this bug's criteria. but i see some stripes, too, which i never encountered with PNGs (or any image) before. those are handeled in Bug 83289, i think. conclusion: all known bugs. still there. little progress. don't file dups.

*** Bug 133077 has been marked as a duplicate of this bug. ***

*** Bug 133379 has been marked as a duplicate of this bug. ***

*** Bug 132041 has been marked as a duplicate of this bug. ***

Ok, I've had a look at this, and can see a clear pattern for the redrawing errors when you move things over your average PNG (that has an alpha channel). It seems that whenever the image is redrawn, Mozilla only redraws the invalidated region (a good thing). However, it seems that when calculating what part of the image should go in this region, the top is not calculated (at all, it seems), so while the invalidated region contains the correct part of the image horizontally, the top of the invalidated region is *always* the top of the image. Which isn't always right.

Almost correct, but the top does pay some part in the problem. Please see comments 45 and 46 http://bugzilla.mozilla.org/show_bug.cgi?id=121230#c45

WRT comment #45, I don't (myself) quite follow the explanation, but I can clearly say that, for me, Mozilla is drawing the image as if it forgot to calculate the top of the invalidated region. I would add that this is only for moving stuff over an image, and the "up-side down" explanation in #45 may well be true for scrolling. If you look at the first two attachement of bug #133077, you can see that the top of the image is being drawn at the top of the invalidated region, and while comment #45 is probably correct, I can't see how it explains the top of the image always being drawn at the top of the invalidated region. http://bugzilla.mozilla.org/attachment.cgi?id=75807&action=view http://bugzilla.mozilla.org/attachment.cgi?id=75809&action=view

*** Bug 133972 has been marked as a duplicate of this bug. ***

*** Bug 134154 has been marked as a duplicate of this bug. ***

I was researching bug 133632 when I found both it bug 134003 to be duplicates of this one. They confirm the findings stated here. I'll try to sum up what we know : This bug affects PNG with an alpha channel ONLY - whether or not that channel is used. PNG's using palettebased tranparency are not affected. This bug affects Windows versions .. seemingly all of them. It causes the updated parts of a PNG image to be displayed incorrectly when the page is scrolled, a window is dragged over it, the rightclick menu is activated on top of it , and presumably in any way the image can be updated. Leftclicking or rightclicking the image seems to update its display correctly This only affects image that have done loading. Image that ARE loading or have been forced to stop loading (by pressing the stop button in the browser) are NOT affected. It does not matter what kind of tag the image is enclosed in , though DIV's seem to have futher problems ( see bug 125629 and bug 125581 - I think theese two may be the same bug as each other .. and possibly as this) It makes no difference if displayed from http: , ftp: or file: HOWEVER .. and this is interesting to say the least .. if you bring up the page info on the page in question and view the image in the media section .. resize the window to be small enough to allow scrolling and then scroll , then everything works just fine. If this uses a different code to display the PNG's then we may have a fix right there .. if not , it still sheds light on what conditions this bug occurs under. .. Why does it occur in the main browser and not in the page info ? (Someone please check if it doesn't occur in other parts of Mozilla too .. mail or news f.x.) As stated in comment 45 and in comment 5 in bug 133632 , there is a special pattern to the way the PNG's are displayed incorrectly. The order of lines displayed are correct but the starting point seems to be in reverse order when going up or down. Left right scrolling the page doesn't trigger this bug but dragging a window over the image left or right does. (dragging SE NE SW or NW produce weird effects) This bug is a regression - Earlier builds did not experience this bug. Seing as version 1.0 should be a base to build on and the first real non-beta version I feel it cannot have a bug as serious as this and this bug should therefore block version 1.0 and it should be fixed ASAP. (If I left something out summarizing the bug please post updates.) (I'm using build 2002032708 on WinXP btw)

*** Bug 134003 has been marked as a duplicate of this bug. ***

*** Bug 133632 has been marked as a duplicate of this bug. ***

*** Bug 134413 has been marked as a duplicate of this bug. ***

I agree with Christian in comment 74. This 1.0 should *not* be released with this issue. This is a very visible regression. Check out this screenshot on imagelib's own psuedo-evangelism site: http://www.libpr0n.com/ . http://bugzilla.mozilla.org/showattachment.cgi?attach_id=76909 That happened by loading the page (and making sure a vertical scrollbar exists), scrolling down, and then back up again. This was done using build 2002033009 on Win2k (sp2sr1). Jake

Please see my testcases at http://bugzilla.mozilla.org/show_bug.cgi?id=125581#c5 (3 comments) This bug has serious forward compatability problems, particularly if it is included in AOL 8. In a couple of years, alpha-transparent PNGs will be much more common on the web. But I wouldn't want to use them if I knew that 10% of my audience were seeing this bug (which is easily possible with AOL8).

*** Bug 134591 has been marked as a duplicate of this bug. ***

I've done my best to find the problem in the code, and I think it occurs when the INIT function is called. I think that for some reason INIT is being called with aY (the y-positioning variable) set to 0. I couldn't find where INIT was being called from though. Hope that helps anyway.

*** Bug 134629 has been marked as a duplicate of this bug. ***

*** Bug 134616 has been marked as a duplicate of this bug. ***

Good that people seem to agree on the "we can't ship Mozilla 1.0 like this" matter. Will someone with sufficient privileges please change this bug to block a Mozilla 1.0 release ?

to Comment #79 From Ian Thomas: you wouldn't use transparant pngs, if even only 10% of your audience encounters problems using them? then you'd probably NEVER get to use them. you know that IE handles only 1bit transparent pngs correctly and applies the (optionally) saved background color of a PNG to your 8bit-alpha mask? until we got this fixed, the only windows-browser doing this right is opera6+ Comment #84 From Christian 'CeeJay' Jensen: this issue is not that trivial. everyone can set severity to blocker, or retarget the bug. but watch what pavlov does to you then. you've been warned. he and only he will set those. and he has also other issues on his plate. go voting (http://bugzilla.mozilla.org/showvotes.cgi?voteon=121230) instead. i agree that m1.0 should include a fix for this, but it's up to you to discuss this with eg. pavlov -- AND NOT TO MOAN ON THIS BUG -- IT'S LONG(!!) ENOUGH. and comments like this (not describing the bug or adding new information) should be carried out in the newsgroups or mozillazine. and btw, we already ARE on bug 134771's dependency list. so, let's concentrate on technical issues here, and develop an apropriate fix instead of talking and pushing.

Does anybody know exactly when this regressed? Comment 35 suggests it was between January 18 and January 22. However, there were no suspicious checkins during that period. A much more likely cause would have been the checkin of bug 98252 on January 9 (07:02 PST).

*** Bug 132164 has been marked as a duplicate of this bug. ***

*** Bug 134999 has been marked as a duplicate of this bug. ***

*** Bug 135038 has been marked as a duplicate of this bug. ***

*** Bug 124705 has been marked as a duplicate of this bug. ***

Could this code have something to do with it? http://lxr.mozilla.org/seamonkey/source/gfx/src/windows/nsImageWin.cpp#488 // Translate to bottom-up coordinates for the source bitmap srcy = mBHead->biHeight - (aSY + aSHeight); http://lxr.mozilla.org/seamonkey/source/gfx/src/windows/nsImageWin.cpp#585 if (8 == mAlphaDepth) { . . gAlphaBlend(TheHDC, aDX, aDY, aDWidth, aDHeight, srcDC, aSX, srcy, aSWidth, aSHeight, blendFunction); } else { ::StretchBlt(TheHDC,aDX,aDY,aDWidth,aDHeight, srcDC,aSX,aSY,aSWidth,aSHeight,rop); The only problem with this theory is that it seems to have been like that forever, but maybe this is an old bug that was only recently exposed by a checkin somewhere else.

David Baron: Please take a look at comment 58 as regards date of regression and possible checkin causes.

Reassigning to Don.

Further to comment 91: 0.9.8 goes through a different code path in nsImageWin::Draw and calls DrawComposited at http://lxr.mozilla.org/mozilla/source/gfx/src/windows/nsImageWin.cpp#528 instead of gAlphaBlend at line 591. Why the change? Because mCanOptimize is true at line 497, which is a consequence of the checkin from bug 104999. I know this has been already dismissed as a possible cause of the regression because this bug was originally filed before that checkin, but note here comment 36. I suggest that the bug in backgrounds was caused before 2002-01-22, maybe by the checkin from bug 98252, and the bug in non-background images was caused (or exposed, as I suggested earlier) by the checkin in bug 104999.

*** Bug 135643 has been marked as a duplicate of this bug. ***

*** Bug 134887 has been marked as a duplicate of this bug. ***

FYI: Clicking the URL bar triggers a repaint that fixes the PNG problems.

*** Bug 136097 has been marked as a duplicate of this bug. ***

If I use the testcase "enhanced reduced test case (5.5kb)".. and I put a break point in the tile background code.. testing for 8 bit alpha.. basically the patch I made for bug 98252.. it never hits that code.. the png's are still updated incorrectly. If I back out the changes for 98252.. just by setting and if that tests for alphaDepth == 8.. it still draws poorly. The update is wrong, the image is upside down, and the top is pushed. I don't even see any backgrounds in the page.. so that tiling code is not the culprit. I am using the build from April 6. Now at work I did a pull for April 9 and I could not get any of the bugs, so I will update my home machine to the April 9 build see if I have any of the problems.

Don: FYI: The test case for bug 136097 is very reproducible for me using 2002040503 build on WinXP.

Don: FYI I am still seeing the problem using 2002040903 build on WinXP using the test case in bug 136097. Load http://www.debianplanet.org/ and scroll 3/4 of the way down the page to where the image of a box with a swirl is located. If you scroll the trashcan partly off the page then back on; it updates incorrectly.

Is this bug the same problem as http://213.239.154.12/~mrtg/213.239.154.3_17.html ?

If those images are PNG (which is the case) in 24-bit color and have an 8-bit alpha channel, yes.

*** Bug 136387 has been marked as a duplicate of this bug. ***

My NT 4.0 box at work.. everything works great. My windows 2K machine at home, the PNG's are messed up. With my maching at home.. the 8 bit alpha code in nsImageWin is never called.. and my 4.0 NT box.. the 8 bit alpha is called. OS 8 bit alpha PNG's upside down bad update images stop at top 4.0 yes no no no W2K no yes yes yes I am looking at the PNG creation.. since an 8 bit alpha png is not even created on win 2k and it is created on my windows NT 4.0 box.

ok.. the difference I found on my NT 4.0 machine and my windows 2K machine is the following.... the gAlphaBlend proc is filled in for W2K(broken) and not for windows NT 4.0(appears to work). If I make that proc null on my W2K machine.. the problems goes away.. at least the symptoms of the image upside down, bad updates, etc. All appears normal. I am not sure how this regressed, it seems that has been there for awhile.. The gAlphaBlend procedure is currently the difference between working and not working as far as my machines are concerned.

srcy = mBHead->biHeight - (aSY + aSHeight); This line if for DIB.. when we blit because the bitmap goes from the bottom up.. for DDB's this is not the case.. so this is wrong.. and aSY needs to be passed to the gAlphaBlend function. All my test cases render correctly.

srcy = mBHead->biHeight - (aSY + aSHeight); This line if for DIB.. when we blit because the bitmap goes from the bottom up.. for DDB's this is not the case.. so this is wrong.. and aSY needs to be passed to the gAlphaBlend function. I am not sure what happend.. if we had this all the time.. but all my test cases now work.

Comment on attachment 78632 [details] [diff] [review] Patch to fix the neg height.. r=kmcclusk@netscape.com

Comment on attachment 78632 [details] [diff] [review] Patch to fix the neg height.. sr=attinasi

Comment on attachment 78632 [details] [diff] [review] Patch to fix the neg height.. a=tor

This was checked into the trunk.. please test away before I check into the 1.0 branch.

This fixes the problem for images in <img> tags, but it doesn't work for background images. See the testcases at http://bugzilla.mozilla.org/show_bug.cgi?id=125581#c5 I'm running 2002041103 on win2000. Thanks for finally working on this. (the trunk is seriously broken btw, I can't use mailnews and can hardly use navigator)

WHOHOOOHOO! i (reporter) can verify this fix to work on replaced html elements (IMG tags). the issue with PNG in background is still remaining. so i suggest marking this bug as fixed and reopening bug 123511, which deals with PNGs in background, since the discussion on this bug has gone very very long already. bug 123511 could than have this (bug 121230) as dependency. what does everyone think about that? dcone: i can see no regression so far. would be ok for me to check into 1.0branch, or do we want to test this a little longer just for safety?

*** Bug 137072 has been marked as a duplicate of this bug. ***

The other problems brought up in this bug are addressed by other bugs. I think all the major issues that caused this problem have been addressed and fixed. I think this is ready to check into the branch.

tpreston: Could you verify the fix on the trunk? Thanks!

Waiting for Teri's verification before we accpet this for 1.0 - ADT

*** Bug 137179 has been marked as a duplicate of this bug. ***

The URL listed is fixed, images are not messed up on trunk win 2k build 2002041203 but the original report listed below is not fixed

Actually, I was talking about the background problem and that is addressed in bugbug 123511 so this bug is fixed on trunk ;-)

I just downloaded the latest nightly build, and all the PNG problems I'd been having are 100% fixed. Great work, guys! :)

*** Bug 123501 has been marked as a duplicate of this bug. ***

adt1.0.0+ (on ADT's behalf) for checking into the 1.0 branch. Pls check this one in asap, and replace adt1.0.0+ with fixed1.0.0 keyword. After QA has verified the fix is in the branch, pls replace fixed1.0.0, with verified1.0.0.

testing on XP gmake build 2002041408 nothing is fixed here: http://www.libpng.org/pub/png/pngs-img-bg.html looks as bad as ever when scrolling.

R.K.Aa: See comment 121.

Ahh no, I meant to say that *nothing* is fixed here, testing on XP, 2002041408 Verified duplicate bug 124657: http://www.hacksrus.com/~ginda/chatzilla/faces.pl Not fixed Verified duplicate bug 123266: http://www.libpr0n.com/ Not fixed etc.etc.etc.

All WFM, same build (non-GMAKE), same OS. The only thing that doesn't work is PNGs as backgrounds and that's bug 123511.

Well.. This is weird. The gmake build 2002041408 utterly fails. Clean install. I now downloaded the "usual" (nmake) version - same build ID - another clean install - and there it's fixed.

Resolving as FIXED. Please add fixed1.0.0 keyword after the fix has been checked into the 1.0.0 branch.

Terri is this fixed on the trunk? Does it cause any visible regressions?

yes, this is fixed on trunk build 2002041503, I don't see any regressions so far, my understanding is that this has been checked into branch today, will check that out tomorrow too

Bonsai verifies that this has landed on the branch. adding 'fixed1.0.0' keyword to trigger QA verification. 04/15/2002 17:00dcone%netscape.com mozilla/ gfx/ src/ windows/ nsImageWin.cpp 3.92.2.2 MOZILLA_1_0_0_BRANCH 2/2 b=121230 r=kmcclusk sr=attinasi a=tor. ADT+ approved. Fix PNG rendering.

Yes this has been checked in on the trunk and branch.

*** Bug 137761 has been marked as a duplicate of this bug. ***

*** Bug 137360 has been marked as a duplicate of this bug. ***

*** Bug 128062 has been marked as a duplicate of this bug. ***

*** Bug 131796 has been marked as a duplicate of this bug. ***

*** Bug 133385 has been marked as a duplicate of this bug. ***

*** Bug 135890 has been marked as a duplicate of this bug. ***

*** Bug 131866 has been marked as a duplicate of this bug. ***

*** Bug 131179 has been marked as a duplicate of this bug. ***

verified fixed on Win 2k branch build 2002041617

*** Bug 138430 has been marked as a duplicate of this bug. ***

Erm, I'm still getting scroll errors with the PNG at the top of http://demoni.ca/~unit3/ (http://demoni.ca/~unit3/bio/unit3-bio.png) on Win2K 1.0RC3 (2002052306). Can anyone verify if this is the same problem or a new one?

I am testing using Netscape 7 PR1 on Win2000. Yes, this is the same problem that has always occured when transparent PNGs are used as background images. This bug only fixed the problem with regards to PNGs displayed using the <IMG> tag (and perhaps other methods that I can't think of). This has been fixed in bug 137223 It has been fixed on the trunk builds since 2002051508 It will be fixed in release builds from Mozilla 1.0.1 (it will NOT be fixed in 1.0)

No wonder I never use a release build. Trunk builds are almost *always* better. Heck, if the latest Trunk build was released as Mozilla 1.0, I'd be happy as a peach (assuming peaches are immersed in true happiness). Looking at what 1.0 *won't* have that the trunk builds *have* I can't, in good conscience, turn back. I'll be forever doomed to using better, faster, bug fixed Trunk builds. Woe is me! Jake

Re: comment #147 Well, thing is, trunk builds are also less stable, which is a big problem. So while branch builds aren't as up-to-date, they are more stable.