Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9+) Gecko/20010529 Scrolling page with images (jpg) causes white lines in the images. This bug may or may not be related to theother bugs on corrupted images (i suggest to make it a dependency). Try this link: http://members.es.tripod.de/ssaammwweell/thumbs1.html SPAM: Yes, those are some very cool Quake 3 wallpapers :)

not seeing win98 2001052920 we do have a imagelib component..

wfm with win2k build 20010529.. (CVS opt)

I'm definetely still seeing this on winNT, build 2001-05-30, voodoo3-3000, 1280x1024x64k colors, 228MB RAM

I can reproduce this as well. I am running Win2K (SP2 applied) using Mozilla 2001052904. My computer has video settings which are currently 1280x1024x32 bits color (GeForce card) and I have 256MB system ram. If you go to www.lemure.net, you will notice two jpgs at the bottom of the page. Scrolling up and down will cause the one on the left to display the problem, but the one on the right is OK!!! There might be a clue here. I thought maybe that the jpg's were encoded differently, but they both appear to be v1.0, standard Huffman-encodeded files (as reported by Paint Shop Pro). One thing that PSPro reports differentely between the two images is that the misbehaving one reports "unknown" pixels per inch, whereas the behaving one reports 100 pixels per inch. In other words, there appears to be at least a slight file formatting difference. Perhaps this is related?

I see this under i386 Linux, build 2001060713. Confirming, setting OS to All. Another URL where this occurs is http://amber.mcs.kent.edu/~ryouko/LUNAR/HTMLS/Treasure.html. Go down to the one labeled "More Lunar Wallpapers!". Note that a lot of the other images don't have problems.

Another important thing to note: The problem is not limited to JPG files! I have come across this problem with GIF's as well. Using 2001060703 on Win2k. See http://msdn.microsoft.com/library/techart/msdn_mfc4ce.htm The first dialog box gif on the page doesnt have the problem but the next two do.

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

Same problem on http://news.bbc.co.uk: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010616 BuildID: 2001061606 Reproducible: Always Steps to Reproduces 1.open http://news.bbc.co.uk 2.scroll down to see images (On the right hand side) with white lines 3.Mouse over the last image and you will notice all images refesh and most images are then displayed ok. Note: It is mostly images built below the current display area that have this problem.

Bug 85804 shows PNG problems, as well.

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010618 BuildID: 2001061808 Has any one else noticed, that on some pages you can also get a stripe, on _simple_ lines of text, usually the bottom or top, (I don't think I have seen it through the middle of the text), and scrolling up & down fixes the problem.

I have just been playing around, on: http://members.es.tripod.de/ssaammwweell/thumbs1.html 1) right mouse clink and choose save image (but don't save the image) 2) move the same file box about, you will observer lots of white lines 3) cancel the save file 4) the white lines will remain 5) click on the image the image will refresh - the lines will disapear. In http://news.bbc.co.uk, although the first page seems to be ok now, there are mon examples on the headlines page (sci/tec etc) mouse over some of the small story links beneath the pictures, on some you may see the line of text refresh, so that the text is fully displayed. Mouse over the images they will refresh and the lines will disapear. My reading of this you don't have a problem with images as such, but with some sort of draw/refresh problem.

It looks to me like a "clipping" problem against the bottom edge of the window in which the images etc are rendered. 1 row of pixels is sometimes not redrawn as you scroll up and down, almost as if the clipping/refresh in conjunction with the scroll is wonky. More PNG images which demonstrate this can be found at: http://www.wild-magic.com/Applications/Applications.html In particular if you look at one of the images, say MorphingFace2.png. Now scroll up and down until this occurs, then get a screen capture of this image (Alt-Prtsc on a Windows box). If you zoom in on this image you will notice that it is always 1 row of pixels (I have never seen it wider than this) that is affected. In addition, it does NOT affect the image border. Note these images are drawn with a 1 pixel border via the following statement: <td><img src="../Images/Data/MorphingFace2.png" border=1></td> I am not familiar with the source/algorithms in Mozilla for doing this... but I hope this information is useful in tracking it down. By the way, using BuildID 2001061304 on Win2K.

I've been seeing this in a lot of places. Some things I've noticed: 1) If an image is repeated in another <IMG> tag, one might do it while the other doesn't. http://slashdot.org 2) It only does it when you move it (or another window) up and down, not left and right. Use the annonying pop-up ad at that quake site to show it. I did some looking around, at it seems to only happen with images where the size is given. Unless someone can find a counter example, I think we should invite the fine folks from bug 74313 for a party. Linux 2001062021 ****. Now i'm getting it in the scroll bar of the Additional Comments box. I'm thinking a new bug for that one.

linux 2001062021 It seems to me its a refresh problem. As point (2) above says _ANY_ popup box draged overimages, showing this problem, can cause the white lines. On (2) above - it use to do it left and right as well, but now it appear, with this build, only up and down. (Back to http://www.bbc.co.uk (wolrd section), everthing looks ok today, unless you look very carefully and then you see the problem. If you use the pop-up box and drag it around a bit you can make some images totally disappear. (click or mouse over to make them reappear))

Updating kw to mozilla0.9.3 since mozilla0.9.1 is gone, and 0.9.2 is just around the corner. BTW, does anyone else think the component should be Compositor, since when you click on the image, the problem goes away?

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

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

I see this behavior even on text, not only on images... When i slide the page up slowly some horizontal white stripes appear sometimes. Not as often as within images, but they are there, too. I use the Mozilla 0.9.2 build 2001062823 under Linux.

I've got an additional comment... I found out, that in the test-page at http://members.es.tripod.de/ssaammwweell/thumbs1.html only those images get the stripes which are not the biggest in that row of the table, so only if they don't give the table their height... Perhaps that helps??

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

When I look at http://members.es.tripod.de/ssaammwweell/thumbs1.html I get the white lines also (horizontal)

I just fond a site where we have the problem just with vertical stripes, and only when you move any other window across the screen. As it is not needed to be a Mozilla-window it really seems to ba a refresh-bug. Just try yourself at: http://www.entry.de/

I have the same problem with linux 2001061108 (e.g.: http://www.proc.org/fandom/cons/garching/samstag.htm) But when you click on the image the lines disappear. After scrolling down (the image is no longer visible) and scolling back the lines are also back.

Doesn't look like this is getting fixed before the freeze tomorrow night. Pushing out a milestone. Please correct if I'm mistaken.

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

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

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

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

bottom right image at http://www.kernel.org gets easily corrupted with scrolling

Odd... `powered by linux' on 2001062823 does not get mis-displayed no matter what I do. In fact, nothing on kernel.org does.

The png test page at http://www.libpng.org/pub/png/pngs-img-bg.html shows this bug. Check out the owl at bottom of page, also images to right and above owl. Other images are not effected. Using CVS 8/13 on Win98

NONE of the images on that page show the bug for me. Linux 2001081106 This will be hard to fix if everyone is seeing different stuff

I am running build 2001081504 under Windows 2000 at 1280x1024 x 32bit colors (with Large fonts) and I am running it full screen. I can see the same effect in a few of the images on the above page (http://www.libpng.org/pub/png/pngs-img-bg.html)... Specifically, on the 3 horizontal parrots and the Ice picture (kitty corner to the owl). You can do this by scrolling it partially out of the window and back. Alternatively, you can right click to bring up a context menu which partically occludes the picture and when you dismiss the menu the lines at the dialog edge will appear. I have been able to consistently produce this for months. It happens very frequently for me. I wonder if the screen resolution is an issue... perhaps there is some rounding error in calculating clipping regions as a function of window size and picture size???

I didn't think I could reproduce this anymore (fizzilla build) because I haven't seen it in a while but I just found I can by making the window very tall and skinny (like smaller than the owl is wide) and shaking the horizontal slider back and forth violently for a while. The lines do appear eventually.

We need to track who is seeing what. I see those parrots page perfectly, so for now i am asumming that linux users can see png fine, and have problems with jpg and gif, while the problem in windows seems to go the other way around. However, my original testcase was kernel.org, the fox image on the bottom right. This is fixed now. Maybe the removal of the old imagelib code fixed this.

To summarize by image type and web page, here is what I see on Windows 2000 with 2001081504 (1280x1024x32bits color): 1) http://members.es.tripod.de/ssaammwweell/thumbs1.html - This contains a bunch of JPG files (quake 3 images), many of which (but not all) show the problem! 2) http://www.wild-magic.com/Applications/Applications.html - This shows a bunch of PNG files which manifest this problem (scroll down to the Bezier surface section and below). In fact, every images except 1 (portals5.png) have this problem for me. 3) http://www.entry.de/ -- This one is harder for me to reproduce. This page displays a big GIF file (map of Germany). By default I cannot get the lines to display when I have my browser window maximized. However, if I resize my browser window to 913x810 and then right click to bring up the context menu in the middle of the image and dismiss it. I can get the vertical lines to appear. Whereas if I Resize to 680x548 the lines go away again. This is why I postulated above that it might be some kind of roundoff problem in the clipping routines that is a function of window size and image size. If someone could point me where to look in the source for this I might be able to track it down. I have seen it on other GIFs as well. Unfortunately my posted source for GIF's (see entry above) at http://msdn.microsoft.com/library/techart/msdn_mfc4ce.htm has been moved. Hope this is helpful.

Hmmm. ALL those webpages are working fine in linux 2001081514, which leads me to think that this bug has become windows only. Can another linux user confirm this? Using 1024x768x16

The fizzilla build doesn't run on Windows. :) (Mac OS X)

I can confirm the problem in Linux 4.06/X4.1/KDE 2.1.1 1600x1200x16 on http://members.es.tripod.de/ssaammwweell/thumbs1.html, but not the other two. I originally created a bug that described the problem with emoticons in the mail reader. That bug was marked a duplicate of this one. Maybe the problem shows up easier using small graphics.

You forgot to post your build number.

Sorry about the build. I built a CVS version 8/13/01. I guess its a little dated. ;)

Please get a new build asap and report back on all pages tested here. egrochowski@vorum.com, please get a build of the 18th or up. I havent checked if your build is a "branch" build, if it is, then the old imagelib removal wasn't done in that day, it was done the 17th i think.

I am now running Build 2001082008 (trunk) on Win2K at 1280x1024x32bit and I get the exact same results as I reported yesterday (on 2001-08-20 13:42). Specifically, I see the same problems with the following pages for JPG, PNG, and GIF files: 1) http://members.es.tripod.de/ssaammwweell/thumbs1.html 2) http://www.wild-magic.com/Applications/Applications.html - 3) http://www.entry.de/ See instructions in my previous post for further comments on each page.

I am still getting the horizontal lines on a Linux CVS build that just finished a few minutes ago. I retested http://members.es.tripod.de/ssaammwweell/thumbs1.html

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

Further clue: Using the page from http://www.wild-magic.com/Applications/Applications.html, I had previously noticed that there was 1 image on this page which did not get the lines during scrolling (namely portals5.png). Perusing the page source and the images. The images seem to be all sized to 320x240 and embedded in tables where the size is given as 320x240...EXCEPT for portals5.png. This image is sized at 319x240 but the table definition in the source which is given as: <td><img src="../Images/Data/Portals5.png" width=320 height=240 alt="portals 5" border=1></td> I made a local copy, resized the image to 320x240 and voila it was now behaving like the other images and manifesting the same scroll line issues. This may lend credence to my previous hypothesis that there is something related to sizing of images; perhaps roundoff errors in the windows expose/clipping area sizes when other objects occlude an image. On a related note... doesnt everyone see this? This is the one thing in Mozilla the consistently drives me nuts!

Although I have reported in the past seen as haven seen this problem quite often. I can nolonger reproduce this on a modern build on either linux or windows 2000 (my current windows build is 2001020110 and my linux build is even more recent). Maybe you could/should try to retest on a new build and post your results.

Darn... I forgot to mention in my comment from yesterday that I am using build 2001082703 (trunk) and running under Windows 2000 (sp2 applied) at 1280 x 1024x32bit. I still see these problems quite regularly. this is now 3 days old.

What happens when you put your resolution to 1024x768x16? Try also resizing your browser window.

Eureka- The font size is the variable! Using Build 2001082703 (trunk): - First I verified that changing to 1024x768x16bit behaved exactly the same (namely it was still problematic). Next I changed from Large fonts (120dpi) which all my previous tests and reports used, to Small Fonts (96dpi) and retested! At both 1024x768x16bit with small fonts AND 1280x1024x32bit with small fonts, ALL the test cases were OK! No wonder, it hasnt been as widely reported as I would have suspected... it seems to mostly manifest itself (under win2K on my system) using Large fonts!

That wouldn't affect the MacOS and Linux users reporting the same problem, though. FWIW, this is the one bug that prevents me from using Mozilla in public (presentations,kisoks,etc.). I use it for checking my own authoring, and when someone's in my office looking at a proof and the images break up they always say, "what the heck kind of crappy browser is that?" I just slap 'em but it seems strange to future this since it's SO visible.

I cannt believe this one is now marked FUTURE either! As I mentioned, I use Large fonts on Win2K and I see this very often and it is VERY in your face. Another GIF example that shows this is at (Build 2001082703): http://www.codeguru.com/algorithms/crc32.html The dialog box at the top of the page. I certainly think this target milestone needs moving up... how does that get done?

bdubbs@swbell.net , please report about your system as much as you can, distribution, kernel, window manager, Xfree86 version, xfs usage, current X server dpi configure, everything you can. I am using mandrake 8 with kernel 2.4.9, Xfree 4.1.0, kde 2.2, using 75dpi fonts, and making mozilla use fonts at either system setting or also 96dpi Since around the 15th i can no longer reproduce this Any other linux user having this problem?

I am using linuxfromscratch as a distribution--In other words I roll my own. I'm using Linux 2.4.6, X4.1 (no xfs), KDE 2.1.1, 1600x1200x16, 100 dpi. I use gcc 2.95.2.1 and havn't been able to make a new Mozilla for a while due to a build problem. I'll try again tonight.

A fresh build from cvs (2001090111) still has the problem in Linux.

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

I'm getting this problem quite often on Linux. I'm using Moz 0.9.4. An example page is http://sunsite.org.uk/ Here the two elephants get white lines across them. Using RedHat 7.1 with XFree86-4.0.3, Kernel 2.4.3, Sawfish, Gnome Desktop, xfs is being used as a server, I'm using a truetype font in moz (Arial, 14pt), Xfree86 resolution is set as 100x100 dpi. From xdpyinfo: screen #0: dimensions: 1280x1024 pixels (325x260 millimeters) resolution: 100x100 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x31 depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 64x64 I'll try and attach a screenshot.

I see this problem both on OS/2 and Linux with Mozilla 0.9.4 ("Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:0.9.4) Gecko/20010918" and "Mozilla/5.0 (X11; U; Linux i686; en-US; rv0.9.4) Gecko/20010913" respectively from the about: page). I note that the number and spacing of the lines is influenced by the speed with which I scroll the page. Yet another example of the bug: http://www.atthefaire.com/index.html; note that the _A Knight's Tale_ "poster" image does _not_ have the problem, but the image directly below it _does_.

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

this is a VERY visible bug and should be fixed before 0.9.5.

11 duplicates, 18 votes. mostfreq?

mostfreq isn't any more ( Have a look at http://bugzilla.mozilla.org/duplicates.cgi ) May this bug affect the "V" in combo boxes, too ? (->screenshot) I see this random effect if I scroll up any Bugzilla page.

For me, this regressed between http://ftp.mozilla.org/pub/mozilla/nightly/2001-09-04-08-trunk/mozilla-i686-pc-linux-gnu-sea.tar.gz and http://ftp.mozilla.org/pub/mozilla/nightly/2001-09-05-08-trunk/mozilla-i686-pc-linux-gnu-sea.tar.gz I.e. it works in Sept 04 build, this bug reappears in Sept 05 build. The only checkin that I could see related to this would be dbaron's wrt the browser.display.screen_resolution preference. (bug 69205) I commented out the line setting my screen_resolution to 80 (which is correct for me), then mozilla took the dpi value from X (which is also set to 80). I still had the bug. So then, I went into Preferences->Appearance->Fonts and changed my screen resolution to 96 dpi. I then went back to my testcase (http://www.atthefaire.com/index.htm) and tested it out. Success! I no longer see this bug! Change the setting back to "System setting", restart Mozilla, and I see the bug again. Can others confirm my findings? (I.e. that this problem is dependent on the dpi.) Thanks. BTW, I'm running XFree 4.1.0.1 (Debian/unstable) ATI Mach64 1024x768x24bppx85Hz on a 17" monitor.

dbaron: can you please take a look, if you caused this regression?

I set my Mozilla to 84 dpi using that clever little calibrator and now I'm getting scrolling artifacts in *text*. Just <h2> enclosed strings! I think you're on to something here. I haven't seen the striped images yet, but perhaps that's just a side-effect of a scrolling bug. fizzilla 2001091313.

Back on 8-31-2001 I made similar comments for Windows 2000. Specifically, I noticed at that time, that when I changed font sizes (from large font to small fonts) on my OS the problems went away. This is still the case wotj 2001092803. In my case, at 1280x1024x32 bits and large fonts - 120DPI - p2t = 15.0 at 1280x1024x32 bits and small fonts - 96dpi = p2t = 12.0. In the layout code there seems to be many dependencies on the pixels-to-twips (i.e. p2t) for sizing calculations. It would be interesting for the Linux problems to know what the p2t values are for the working and non-working cases, to see if their is some correlation.

> dbaron: can you please take a look, if you caused this regression? This could perhaps be a rounding issue related to cases where p2t is not an integer, or something like that, except we always round it to ensure that it is an integer (bug 16200). I wouldn't be surprised if it's something that shows up only at some logical resolutions, so I suspect making the DPI setting work could have caused it to "regress", but I wouldn't really call that a regression from my change since it would have been broken with those DPI settings before my change. (This is assuming it actually was my change that caused it to start happening...)

Still, if this were the same as bug 16200, it would: * never show up on the GTK port (Linux) * only show up at resolutions that are not integral divisors of 1440 (such as 60, 72, 80, 90, 96, 120, 144, 160 dpi)

dbaron: I just read the report for bug 16200, and I do not think this one is the same one either. However, I do think it is another in the category of bug 63336. The reason is that while scrolling is a factor, I find general expose/clipping redraws of images cause the same results. For example, on Windows, right click on a problem image to bring up the context menu so as to partially occlude the image and then dismiss it. It will display the line artifact either horizontally or vertically (or both) in line with the edge of the context pop up menu dialog. Also, my comment from 2001-08-29 seems to show something related to Image redrawing that is image specific. On that web page, you have two specific images side by side, scroll through them, one gets the horizontal lines and the other doesn't (their declared image sizes are 1 pixel different).

Could anyone who is seeing this please try the patch in bug 104544?

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

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

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

Patch in bug 104544 works for me (at least on one page I've tested).

I'm running 0.9.5 on Win98 and have seen this for since maybe 0.9.1? I can't remember. Following advice, I looked at Mozilla's font display resolution (Preferences -> Appearance -> Fonts -> Display Res). It was already 96 dpi; changing to 72 dpi or back to 96 dpi didn't eliminate the problem. Looking at other comments for this bug, I changed Windows' fonts from Large (120 dpi), which I have used for a while, to Small (96 dpi). This has eliminated the lines, whether Moz uses 72 or 96 dpi display resolution.

To: Bryan Ryner: Yahooo! The patch from bug 104544 fixes the problem for me! Here are the details: I have been experiencing this problem regularly since at least 2001052904 on Windows 2000 at 1280x1024x32 using Large Fonts. First, I verified that the problem still existed in 0.9.5. Next, I downloaded the latest tarball, built it and confirmed that the problem still existed. Finally, I appled the patch, rebuilt and confirmed that the problem disappeared! I tested on numerous sites on which I can reliably reproduce the problem. I say lets get it approved and checked in to tbe builds ASAP.

As described earlier I had that problem under Linux, too. Now I was using Mozila 0.9.5 and the XFree-Server version 4.0 with the module 'nvidia' ver.1.0.4 at an resolution of 1152x864. The problems appeared at 75, 96 dpi and system setting. Now I am using an GeForce2 MX instead of the old TNT and had to update the X-Server to 4.0.2 using the module 'nvidia' ver.1.0.1541. Now all the problems disappeared at all dpi-settings and at the same resolution and the same 'unpatched' Mozilla 0.9.5! So this bug seems to depend on the X-Server, too....

For what its worth, scrolling slowly makes this problem much worse, while scrolling quickyly can almost eliminate it. I rarely see this when using PgUp/PgDown to scroll. Also, switching to another tab and then switching back seems to clean up all the images for me. I'm running moz 2001101201, X 4.0.1 with the Nvidia 1251 drivers under RH 7.0

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

My system is Windows2000(SP2) with GeForceMX Videochip. But my system don't reproduce this bug. Bugzilla-jp is reported same problem. http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=1572 This bug reporter said,When vertical scrolled webpage with Windows Media Player over the Mozilla Window ,this bug don't reproduce a pile of media player. When this bug reproduced,Invalid Area is Rectangle Only?

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

My XFree dpi is 100x100. Changing Mozilla's pref to read 96dpi fixed this problem for me.

This fix: http://bugzilla.mozilla.org/show_bug.cgi?id=110369 Fixed some image striping issues with odd DPIs. Can we see if this was fixed?

Regarding comment #85 from Michael Kaply, it still is a problem for me at 72 dpi with nightly build 2001111908. I can also confirm that after changing to 96dpi the problem disappears.

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

This Screenshot is Mediaplayer window over Mozilla. http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=394 Invalid area isn't rectangle,this case. (http://www.be.wakwak.com/~tks/) And this site has no table,but 0.9.6 reprodeced. http://member.nifty.ne.jp/Kondoh/GO_TO/go_to.html

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

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

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

Another data point: Mozilla 0.9.6 (2001112012). Mozilla dpi set to system setting; system setting according to xdpyinfo is: screen #0: dimensions: 1280x1024 pixels (361x271 millimeters) resolution: 90x96 dots per inch ... XFree is from Debian Woody, and is a CVS snapshot. Debian version is 4.1.0-9; XFree86 -version prints: ... XFree86 Version 4.1.0.1 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: xx August 2001 ... This image is the first one in a while I've seen this with. The URL (hope it works for you, too...) is <http://images.amazon.com/images/P/B00005OM54.01.THUMBZZZ.jpg>. This is when displayed on the Amazon.com "Electronics > Categories > Computer Add-Ons > Drives & Storage page" (no URL, sorry: They have session id in them).

Happening a lot less often now, but I still see this on certain specific images, reproducably. Example: the second to last image at: http://www.franken.de/users/deco/myfiles/editor.html (image of red and yellow chao on beach, JPEG)

I reported earlier that I don't have this problem anymore with my new X-Server. But that is not true, I forgot restarting the mozilla after changing the dpi-setting. The problem does not occur with the tested 96dpi, 93dpi and 75dpi, but does occur with 92dpi and 72dpi. This are the only values I have tested with the actual mozilla 0.9.6. Based on the last posted URL I have generated a simple testcase which shows the error with GIFs and JPGs and how to turn on and off the wrong repainting with bold and italic text. All tested GIFs and JPGs did work, I just took one of each. The inserted <br>s don't change anything but the appeareance, they could be <p>s or nothing, too. But look yourself at: http://bigboss.dnsalias.com/repaint/test.html

Ah... good test case! My DPI is 80x80, I see it on Thomas' page, on images as well as some of the text. Perhaps /even/ dpi's trigger the rounding error, and /odd/ dpi's don't? (default is 75x75 I believe, so most people wouldn't see it).

Using 75x75 in the x server and 96 dpi in mozilla makes me never see this bug I think we should relnote this

I've had this problem since 0.9.3 and I'm getting very frustrated with it. I'm not sure what I can do that'd be useful, but I'm running the latest drivers from nVidia under Linux with a Riva TNT at 92 DPI.

Deraj, have you tried setting your DPI to 91 or 93 to see if that makes the problem go away?

This bug is still alive and kicking. I think the previous comments and investigations show that it is related to roundoff (twips to pixels) in the code, not to video drivers. Refer to bug 63336 for a general item covering these issues. It is also not just on Linux. I still see this problem in 0.9.6 under Windows 2000 at 1280x1024x32bit (120 dpi, which corresponds to a pixels-to-twips ratio = 15.0) The best example webpage to demonstrate it is: http://www.wild-magic.com/Applications.html Every image on this page displays this phenonmenon on my computer when scrolling.

seeing this at http://www.adobe.com/ using 0.9.6 on NT 4.0, large fonts, 1280x1024x16 with a Number Nine SR9. In color prefs I have use system color and use my colors checked and have a color scheme with a dark background ( http://bugzilla.mozilla.org/attachment.cgi?id=17629&action=view , although the High Contrast Black color scheme that comes with NT works just as well). Happens with the first two and the last circular .GIFs on the page. Interestingly (of diagnostic significance?) it only happens with the top part of the first two such GIFs. As commented before, this has been around for awhile and scrolling slower makes it worse. Using a dark background color scheme can make it more easily apparent.

With 0.9.6 on Win98 I see stripes at 98, 99, 116, 118, 120 and 125 dpi. I see no stripes at 96, 97, 100, 119 and 121 dpi.

This problem with the horizontal lines through the images happens for me under Linux (Radeon, Debian "testing" XF86 4.1.0-7, 1600x1200x24, 100dpi) but not under win2k. It seems to happen more on pages with a lot of images (such as http://www.acme.com/licensemaker/licenses.cgi ). Actually on that page it happens as soon as the page loads, before any scrolling is done. Using 0.9.6 on both platforms. Actually I just changed the DPI setting in the Font preferences to 96 instead of "use system setting" and it went away. Hopefully this will help track down the root of this bug. Wait, this bug has not been assigned to anyone and is still "NEW" after six months? Cripes.

Update: It mysteriously re-appeared for me despite altering the dpi setting, and also happens with form buttons. Apparently I can't read either, I see someone is working on this after all, sorry Stuart. :-)

here's another funky, twisted datapoint: a Google cache copy of a page ( http://www.dj.com/ ) shows stripes, although the original page does not (I asked for http://www.google.com/search?q=%22dow+jones%22+telerate&btnG=Google+Search and poked the cache link, which was http://www.google.com/search?q=cache:WvbNRGemNDY:www.dj.com/+%22dow+jones%22+telerate&hl=en at the time I did this) Wonder what that's all about. . . Anyway, my config's at http://bugzilla.mozilla.org/show_bug.cgi?id=83289#c100 OBTW, I tried http://www.acme.com/licensemaker/licenses.cgi (mentioned in http://bugzilla.mozilla.org/show_bug.cgi?id=83289#c102 ) at a number of different DPIs and none of 'em striped for me.

This only happens to me scrolling down. If I scroll down past an image, and then back up it looks fine.

Yes, that is the whole point. I occurs when the during scrolling if part of the image gets clipped against the edge of the window. Then when it repaints it there is a 1-pixel line. Hence, if you scroll using the Page Up/Page Down keys or by clicking the scrollbar between the thumb and arrows, you might not even see it because it scrolls 1 page at a time (and the odds of clipping an image are lower). Scrolling by clicking the scroll up/down arrows or by dragging the "thumb" increases the odds dramatically... but you still have to have the right conditions for this to happen (Pixel-to-twip ratio, image size, etc). I can also get this to occur by have some other object (like a pop-up context menu) partially clip the image... when it is redrawn, there is a horizontal line. As I have said before, for my computer setup, the single best site to demonstrate this is http://www.wild-magic.com/Applications.html. Go there and scroll down as described above and voila.

hmmmm. http://www.wild-magic.com/Applications.html works fine for me. And I get the stripes on http://www.adobe.com/ scrolling in both directions, not just scrolling down. And the images involved have 0 border width. Perhaps this is not one bug, but a set of related bugs(???).

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

I dont see it at www.adobe.com... however, I have my Browser window maximized (1280x1024) so I can't really scroll down over the images. You must either have a smaller screen resolution or your browser is not maximized. Is this the case? If it is the latter, then you may not see the problems because it is definitely a function of browser screen size. I found that I could re-size my windows on a given problem page (to some magical size where I think the pixel roundoff issues dont occur for the given images) and the problems would disappear.

of course you dont see it when you resize the window. when you page down or page up to display the image, it doesnt render the image in slices as when cursoring or using the slider bar to show progressively more of the image. there must be some off by one mathematical error or the like thats not including that row of pixels in the redrawing. btw, i can exhibit this problem at home sometimes on my moz 0.9.3 and here at work on 0.9.2 (really I should be using 0.9.6 at both locations) but even with these versions that I originally reported the bug on, I do not see any excercizing of the bug on the wild-magic.com pages. its been a month or so since I've seen it again actually, come to think of it. /kc

When I refered to re-sizing: I meant I could resize the window so that subsequent scroll operations would or would not affect things. I agree it is a pixel round off issue. I have been saying so for months. I will attach a part of what I see when I scroll at http://www.wild-magic.com/Applications.html when running Build 2001121003 on Win2K at 1280x1024x32bit.

This is what I see when I scroll at http://www.wild-magic.com/Applications.html

Just for the record - we had a very similar problem with SVG, see bug 114854. It seems to be a rounding thing when converting from twips to pixels. Our solution is to inflate the dirty-rect passed to nsIFrame::Paint() by ~1/2pixel.

Inflating the output rect by 1 pixel works for me (Win98, 120 dpi and 96 dpi) Please check other platforms. I did not manage to create an attachment ("You did not specify a file to attach", but I did) so here is the patch: RCS file: /cvsroot/mozilla/gfx/src/nsRenderingContextImpl.cpp,v retrieving revision 3.25 diff -u -r3.25 nsRenderingContextImpl.cpp --- nsRenderingContextImpl.cpp 2001/12/12 01:35:21 3.25 +++ nsRenderingContextImpl.cpp 2001/12/22 12:30:07 @@ -895,6 +895,10 @@ sr.y = aSrcRect->y; mTranMatrix->TransformNoXLateCoord(&sr.x, &sr.y); + -- pt.x; + -- pt.y; + sr.Inflate (1, 1); + nsCOMPtr<gfxIImageFrame> iframe; aImage->GetCurrentFrame(getter_AddRefs(iframe)); if (!iframe) return NS_ERROR_FAILURE;

Mozilla 0.9.7 Talkback build id 2001122106 (binary download) for Windows 98 A gif with a transparent background is redrawn as a number of separate pieces. A gif with a white (non-transparent) background is redrawn correctly. You can see one example of the problem at http://www.madisonastro.org/check/problems/cal_2002_q1_bad_gif.html (Half of the images break up) and another at http://www.clsurf.com/rasastro/ (Logo in upper left breaks up). This seems to be a problem involving repainting the window, since the broken image is restored to its correct appearance by a single mouse click or by bringing a different browser tab or a different window to the foreground and then returning the html page to the foreground.

Daniel: I think you're wrong, it has nothing to do with transparency. In your first example, everything in the month of Febuary is bad, but the other images are fine.

Bottom two scenes (4 images) at http://www.martinez-destreza.com/fenfot05.htm exibit this behavior too. No other images on the page do. I thought gfx2 was supposed to eliminate "twips". 35 votes... might be nice for 1.0.

I hadn't noticed any white lines on OSX for quite a while, even after switching to an odd DPI, but I just found in a text block that while it's not drawing a white line, it does appear to be just not drawing the line at all. This is clearly visible in the text sample comparison attached. The erroneous render was found as I scrolled down with the arrow keys. After snapshotting it I scrolled away and back and it was rendered properly. I have not seeing the problem with an even DPI.

Yes, I have the same problem as #118 quite a bit of the time. The bug only occurs for me (Linux) when scrolling down. Scrolling up always renders properly. I'm betting this is a related bug, but a different bug, nonetheless. It's also very annoying =(

This patch could be a workaround for the problem. The dirty rect in inflated by one pixel, if possible. Works for me under Win98. What do you think?

I didnt noticed this bug until I upgraded from mozilla 0.9.5 to 0.9.7. My system is RedHat 7.2 i686.

Merging with bug 116496.

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

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

This bug appears on Windows XP (currently running mozilla build 2002013103) Aparently the images are only being partly redrawn untill you click in the address box and it becomes redrawn correctly. A related bug (in which the screen isn't drawn correctly till the address box is clicked on) happens with http://www.mozilla.org/newlayout/xml/debugdemos/books/books.xml , click on any of the buttons, and notice how only part of the screen is updated, then click in the address box and suddenly it's redrawn correctly. See bug http://bugzilla.mozilla.org/show_bug.cgi?id=116593

I still experience this in 0.9.8 (on Win2000) at 1280x1024 using Large fonts. The latest test URL (http://hacks.mit.edu/Hacks/by_year/2001/the_one_ring/) works fine for me, but I still experience problems at http://www.wild-magic.com/Applications.html and a variety of other sites. I have not tried applying the pixel inflation code recently suggested. Does this work for others? Does it break something else, or is there a reason it has not been accepted?

I have investigated this problem a bit. The problem seems in the interal storage using floats in gfx/src/nsTransform2D.cpp. Float's have limited precision, which can cause rounding errors. Attached is a patch that when rounding, first rounds to 0.01, and after that to int's. This is not a nice solution, but for me it seems to work. I think this rounding error can alse be the cause of other pixel-offset problems I am seeing sometimes (like the text moving one pixel to the right)

I get white stripes not only on images but also on text. Before it was mostly images but with 0.9.8 it seems to be more often on text. The images where bad but not so important, on text it is terrible since you can't read it sometimes. I don't know if it is the same bug, but it comes when I scroll and looks the same.

One page where I allways get broken textlines when scrolling up is http://www.linux.org.uk/ But it happens on a lot of places. I saw that people have reported this before. I've seen it before as well, but it seems to be triggered much more often with 0.9.8 then previous versions I have run (all 0.9.x). When you have a small font and the lines are gone the text becomes unredable. I think this is a very important bug. There seems to be a difference between the text bug and the image bug. In the images there are empty (white) lines. With text the line is gone and the height is decreased. It might even be different bugs.

In reference to comment #128 - if you really think it's a nsTransform2D bug, you may want to take a look at bug 97861...

Michiel: i tried your patch, but it does not work for me. I use Win98 with 'large fonts' (120 dpi).

Sorry, i must be more exact: The rounding patch solves the lines problem on many pages for me, but not on all. I still see lines e.g. on http://www.photo.net/gallery/ (bottom two pictures).

MArtin: You colud try to lower the 100.0f's in the patch. They are quite arbitrary. Try to change them in 50, or even 10. But this can introduce some other errors.

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

per adt, critical for nsbeta1. hence plus.

per adt, critical for nsbeta1. hence plus.

Maybe you don't need more test cases, but on cvs-diff listnings from ViewCVS like http://savannah.gnu.org/cgi-bin/viewcvs/savannah/savannah/gnuscripts/sf_cvs.diff?r1=1.32&r2=1.33&diff_format=h I see lots, and lots of white stripes on the colored parts of the table.

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

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

me again (config at http://bugzilla.mozilla.org/show_bug.cgi?id=83289#c100 , but I'm running 0.9.8 now). With 0.9.7 and 0.9.8, I've seen stripes at this site: http://www.homeniscience.com/le_traversin/page1a.html with the interesting feature that images in the same row of a table may exhibit differing behavior. Sometimes it's all the images in the row, none, one to the left, one to the right, one in the middle. Perhaps this might be of some value to someone trying to debug this. Perhaps not.

(pardon the two comments in rapid succession, but) I think I finally found a useful bit of information - rescaled/resized images scroll fine images in their original pixel size get stripes http://bugzilla.mozilla.org/show_bug.cgi?id=83289#c46 reported this, too, but http://www.homeniscience.com/le_traversin/page1a.html provides lots of positive and negative examples and 1 or 2 exceptions (MASQUE.JPG has no stripes and PARIS.GIF is such a sparse image I can't tell one way or the other). There's also an animated .GIF (star.gif) that doesn't seem to stripe. One image (lit.gif) appears twice on the page - once near the top resized (no stripes) and once near the bottom in its native size (with stripes). I'm attaching a text file with a line for each of the img tags on the page. They're preceded by a YES or NO (for whether or not I see stripes) and the native pixel width and height of the image (as reported on Mozilla's title bar when I view the image by itself).

attachment belongs to http://bugzilla.mozilla.org/show_bug.cgi?id=83289#c142

Could you integrate all that into one HTML page, so that it could be easily referenced for testing?

> Could you integrate all that into one HTML page, so that it could be easily > referenced for testing? Great question. I thought it would be great to have something more compact and focused than http://www.homeniscience.com/le_traversin/page1a.html but with the same basic characteristics. So I made a small table with resized and non-resized images side by side, using images culled from .mozilla.org. And it failed to exhibit the problem. So, although http://bugzilla.mozilla.org/showattachment.cgi?attach_id=73563 definitely captures some interesting aspects of the problem, it ain't the whole enchilada. Perhaps someone more versed in in HTML than I (I've barely touched the stuff) who can also see this problem at homeniscience could take a quick stab at capturing its essence. Maybe something will catch your eye that didn't catch mine.

Robert - what DPI (or Pixels-to-twips) settings does your setup correspond to? I can't see your stripes and you can't see mine (comment #112, and comment #99 for my settings). Also, I am running with my browser window maximized. One thing I did notice on your example page (http://www.homeniscience.com/le_traversin/page1a.html) is that I can muck up certain images by popping up a context menu in front and then clearing it. Mas1.jpg, Mas2.jpg, and Mas3.jpg (last 3 big pictures near bottom of page) get screwed up royally. Simply right click on one of these images, the context menu comes up, and then left click outside of box to clear the menu. The refresh of the images under the context menu is screwed up. Jopizza.jpg will also get vertical stripes when I do this, but all the rest are fine!

my font prefs report 96dpi (I remember experimenting with this (#c104) before to no avail). Current window size is 1007x637, although this shifts somewhat over time (and doesn't appear to be critical to reproducing the problem, as long as there's a need to scroll) Rest of config at #c100 I see a context menu glitch, too, but not as serious as yours. Specifically, when I bring up a context menu and cancel it, it clears the stripes underneath where the menu was and leaves a background-color stripe where the top of the menu was. On some images, it also leaves a stripe where the left hand side of the menu was. I have also seen pages where text or images are shifted laterally by one pixel at the point where they scroll into view.

Robert - When I refer to DPI settings, I mean at the OS level not the Mozilla Font size preferences. Under Win2K, you can see this by right clicking on the desktop and getting the Properties->Settings->Advanced->Font Size. On my computer, when these settings are at 120dpi (i.e Large fonts) I can see the problems I reported for the web page at http://www.wild-magic.com/Applications.html When I switch to 96 dpi (small fonts) and view the same page it renders absolutely perfectly. For completeness, I also regularly see lines of text getting mucked up when clipped against the edge of the window during scrolling.

Ok, I can duplicate this bug if i use large fonts. There is a rounding error somewhere in either the transform code or in nsRenderingContextImpl::DrawImage itself, but I can't find it.

Here is a fix that avoids the double rounding in the transform code to avoid the rounding of y to 1 for the dest pt. I have tested this at 120dpi on WildMagic's site.

Good sleuthing, pavlov. Not sure if the stuff under gfx/ is only for image rendering... does this have a chance to fix the font rendering issues too? That one's far worse, although interesting in action. Did you know if you take an 'o', and round away the last column of pixels, it becomes a 'c'? 'i' and 'l' round themselves to nothing. I'm guessing not as many people see that one or it would have gotten a lot more attention a long time ago. I lose a letter or two on most pages. I'm running at 81x81 dpi, fwiw.

Comment on attachment 74489 [details] [diff] [review] avoid the rounding errors r=gagan ignoring the nsTranform2D.cpp patch

please ignore the nsTransform2D part of the patch. that was a typo when looking at the file.

I applied the patch and rebuilt the source on my local machine running Win2000. This patch appears to fix the problems for me. I tried it on 4 known, repeatable, problem sites for me and it worked. This really is good news! Thanks.

I went back to 0.9.8 and replaced gkgfx.dll with a patched one kindly supplied by egrochowski@vorum.com and the stripes at http://www.homeniscience.com/le_traversin/page1a.html went away. Also, 1 pixel mid-character sideways shift that I'd noticed recently when scrolling http://www.computerhistory.org/events/lectures/engelbart_03262002/ also went away.

Since there are lots of other 120 DPI people around in this bug, could you all try http://www.mtelecom.ru referenced in bug http://bugzilla.mozilla.org/show_bug.cgi?id=62219 And see if you get the white vertical lines here? Not image related, but definitely DPI related. Comments go to that bug. Thanks. Thanks

Curious. See also my bug 119824 and bug 88485, which could be related to this.

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

I don't think Bug 132930 us a duplicate of this as it is a single line actual moving through the image while you watch.

I spoke too soon - while the stripes-on-scrolling bug definitely seems to be fixed by the patch (I double checked) the lateral shift bug is not - it just doesn't happen to me consistently on the first scroll, the way that the stripes-on-scrolling bug does. So when I went back to http://www.computerhistory.org/events/lectures/engelbart_03262002/ and http://slashdot.org/ and scrolled back and forth a few times, I was able to see the lateral shift described in http://bugzilla.mozilla.org/show_bug.cgi?id=129400 (BTW, I didn't see any problem at http://www.mtelecom.ru with or without the patch and DID see the problem described in http://bugzilla.mozilla.org/show_bug.cgi?id=132930 even with the patch. In fact, it was so mesmerizing to see the background color stripes flicker down the image that I reloaded it several times just to see the show:-)

Comment on attachment 74489 [details] [diff] [review] avoid the rounding errors >? 83289.diff >Index: nsRenderingContextImpl.cpp >=================================================================== >RCS file: /cvsroot/mozilla/gfx/src/nsRenderingContextImpl.cpp,v >retrieving revision 3.29 >diff -u -r3.29 nsRenderingContextImpl.cpp >--- nsRenderingContextImpl.cpp 6 Feb 2002 15:37:21 -0000 3.29 >+++ nsRenderingContextImpl.cpp 16 Mar 2002 04:17:41 -0000 >@@ -887,8 +887,11 @@ > nsPoint pt; > nsRect sr; > >- pt = *aDestPoint; >- mTranMatrix->TransformCoord(&pt.x, &pt.y); >+ float fX = float(aDestPoint->x), fY = float(aDestPoint->y); >+ mTranMatrix->Transform(&fX, &fY); >+ >+ pt.x = NSToCoordRound(fX); >+ pt.y = NSToCoordRound(fY); Is nsTransform2D::TransformCoord's scale+translate case broken? I don't see why it should be rounding both terms of +, then adding. Please file a bug, note it here. > > sr = *aSrcRect; > mTranMatrix->TransformCoord(&sr.x, &sr.y, &sr.width, &sr.height); >Index: nsTransform2D.cpp >=================================================================== >RCS file: /cvsroot/mozilla/gfx/src/nsTransform2D.cpp,v >retrieving revision 3.11 >diff -u -r3.11 nsTransform2D.cpp >--- nsTransform2D.cpp 6 Nov 2001 01:28:27 -0000 3.11 >+++ nsTransform2D.cpp 16 Mar 2002 04:17:42 -0000 >@@ -405,8 +405,7 @@ > } > > void nsTransform2D :: TransformCoord(nscoord *ptX, nscoord *ptY) >-{ >- float x, y; >+{ float x, y; Argh, this is a gratuitous change, and ugly to boot. Please undo, don't change this file. sr=brendan@mozilla.org with the above. /be > > switch (type) > {

Comment on attachment 74489 [details] [diff] [review] avoid the rounding errors a=roc+moz

fix checked in.

I wrote: >Is nsTransform2D::TransformCoord's scale+translate case broken? I don't see >why it should be rounding both terms of +, then adding. Please file a bug, >note it here. What's the sequel bug? Way to respond to my sr! /be

Brendan... I am not the authority here, but comment 153 does indicate that you should ignore the nsTransform2D part of the patch... it was a typo. Hope that helps.

grabbed the nightly (2002032803). http://www.homeniscience.com/le_traversin/page1a.html looks good, no stripes.

Much better, but not perfect. The stripes within the pictures are gone. But I see sometimes a missing last line on the bottom or on the right of a picture, e.g. in the last two pictures on http://www.photo.net/gallery/ I use build 2002032803 on Win98 with 120 dpi.

um, am I the only one seeing bad image painting upon scrolling? The fix for this bug was supposed to fix this issue, but for me it made if *far* worse. I'm using build 2002033009 on Win2k (sp1sr1). For instance, check out http://www.libpr0n.com/ and make sure there is a vertical scrollbar. Now scrolldown and then scroll back up. Notice the LibPr0n picture all broken up (I will attach a screenshot after this post). I also see this with all w3c standards images and other images (not all). I have my display resolution set to 96dpi (the Mozilla default on Windows) So, did this fix have this effect or is some other bug involved? I dont' remember seeing painting this bad for a long time. Ever since this bug was fixed is when I started seeing this behavior. What's the deal? Jake

That is bug 121230

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

Verified fixed win xp build 2002041617, will check other OS's

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

Adding adt1.0.1+ on behalf of the adt for checkin to the 1.0 branch. When you check this into the branch, please change the mozilla1.0.1+ keyword to fixed1.0.1

this is already in.

Verified fixed win xp branch build 2002072208, linux branch build 2002072306, and Mac OS X branch build 2002072305

it's baaaaaack I'm seeing this with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040518 Firefox/0.8.0+ but not with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 Many of the URLs mentioned here are gone and many do not reproduce the problem for me, but http://www.homeniscience.com/le_traversin/page1a.html still does (see the spa .GIFs about 3/4s of the way down - also the upper left and upper middle animated .GIFs near the bottom of the page, which also show some weird artifacting during the animation). I stumbled onto this today at http://www.edwardtufte.com/tufte/posters at the 2nd PowerPoint .GIF. Finally, I saw something within the last few days at http://www.richswebdesign.com/ (stars1.gif was striping) - but I can no longer reproduce that one or the original http://bugzilla.mozilla.org/show_bug.cgi?id=227498 bug.

at http://www22.verizon.com/forhomedsl/channels/dsl/high-speed+connection.asp I see stripes with both Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040518 Firefox/0.8.0+ and Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 although I don't see as many stripes with the latter and they come and go as I mess with the font size.

I'm seeing this in spades with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040601 Firefox/0.8.0+ (Classic theme, dark background, use system colors, always use my colors) interesting related results in attached .PNGs: http://www.salon.com/tech/wire/2004/05/27/spammer/index_np.html most of the .GIFs here show the problem, but the left middle one doesn't http://www.scientificpsychic.com/graphics/ the animated .GIF near the top of the page shows weird background-color artifacts. If you view it http://www.scientificpsychic.com/graphics/ascend.gif by itself, it has no such problem also, I'm seeing vertical background-color bars when using horizontal scrolling at orkut.com (but I won't post any images or URLs here, 'cause that'd be kinduva privacy violation. I know some of y'all are orkut members, though. . .)

went away in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 (except for the Verizon case; see http://bugzilla.mozilla.org/show_bug.cgi?id=248393) came back in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040705 Firefox/0.8.0+ (noticed at http://www.michaellorenzen.com/carnegie.html , but the Tufte & psychic URLs just above reproduce it, too) Not quite sure whether this should be expected with the split between trunk and branch builds.

it's back again in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 (aka released Firefox 1.0) seen at http://www.cafepress.com/politics/browse/Nao-1_Ntk-All_pv-bettybowers.3932701_p-5_N-20407485_nr-1?zoom=yes#zoom (on the Front Image, but not the Back Image) The Tufte, psychic and Carnegie URLs (see above) show it, too.