When scrolling, often the portion of an image or block of text that was off the screen before is drawn horizontally offset one pixel from the rest of the image. Clicking on the image (even if it is not a link) or selecting a bunch of text around the affected area makes it redraw correctly. This bug existed in my own builds on linux ~1 year ago. It exists now in 0.9.8. It does not go away in 0.9.8 when compiled without optimization. It does not go away in 0.9.8 when compiled with -fsigned-char (I thought it might be a char-signedness bug, but I guess not.) If it's an endian bug, it's in linux-specific code, since it doesn't happen on Sparc Solaris builds (I don't have a Sparc linux system to test on.) It happens in galeon and even in viewer. I'm happy to do more detective work if anyone can point me in the right direction. Reproducible: Always Steps to Reproduce: Find a page with big images. Scroll some. www.salon.com seems particularly susceptible -- those long vertical framing lines usually get skewed pretty fast. But it happens from time to time on most sites. Actual Results: I get images or text where the portion above some horizontal line is shifted one pixel to the left or right of the portion below. Expected Results: Mozilla should have displayed an intact image or piece of text.

I think this has been fixed in the current nightly builds. Could you test the latest one if possible?

OK, I'll try the latest nightly when I get home to my ppc machine.

Nope, it's not fixed. Another way to exhibit the bug is to go to http://slashdot.org and scroll around for a while -- the offset usually occurs in the green item titles, for some reason.

This was produced by the redraw after the URL completion box went away.

I took this one after the screen had redrawn correctly

*** This bug has been marked as a duplicate of 83289 ***

This is a completely different bug than the "white stripes" bug. This doesn't lead to stripes at all, just horizontal misalignment of part of the image, and seems to be powerpc specific. Reopening.

Though I believe I have seen these type of problems before, I can't reproduce with the latest Linux build (2002-03-19-08) under Redhat 6.2

Hmm, I recently saw this same effect on a linux x86 system, so it's not powerpc specific after all. It probably is an X server DPI issue, and may even be caused by the same thing as bug 83289, but the symptoms are different so I'm going to avoid marking it as a duplicate for now. I'll test the patch for 83289 and see if that helps.

I seem to be unable to produce this bug when I set the X server to 96 DPI (before it was set to 100 DPI, as was the X server on the x86 laptop I saw this on.) Next I'm going to try the patch with it set to 100 DPI.

Aren't all of 109296 (?),112673, 118687 (?), 120918, 121920, 122577, 131107, 132164 (?) a dupes of this problem? Isn't this bug a dupe of 80530? Or.. isn't all this stuff a dupe of 63336?

Moving to future since it unlikely to get serious attention for m1.0.

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

Seeing this on PC/Windows. Marking all/all.

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

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

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

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

Relnote: We should have a release note that says that changing the DPI setting may prevent this bug from appearing.

I'd like to check that, but how do I change the DPI in XF86? I couldn't find any info in www.xfree86.org's documentation. Thanks.

Don't change X server DPI settings (if you really want to do it, run Xserver with -dpi option and check it with xdpyinfo). Change mozilla prefs/fonts DPI settings instead.

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

#21: thanks, changing the DPI settings in Mozilla from "System Setting" to 96 "fixed" it on my machine.

The problem persists on Mozilla 1.0RC1 [Windows 2000, P350, Matrox G200, 1600x1200x16bits, and Large fonts]. The default DPI resolution in Prefs->Fonts is 96 and changing it to 120 (then restarting Mozilla) doesn't seem to make any difference. The problem is most apparrent in Slashdot.

It's still not working here either, no matter what I set the DPI to. My DPI in XFree86 is 91x91 and I've tried to set the DPI in mozilla to 96, 91, 72, and many others but I always get graphics bugs in the text when I scroll. Maybe I have to force the X-server to have a DPI like 96 and mozilla to also have 96? (to see the DPI in XFree86 run xdpyinfo). These graphics bugs are the number one problem in mozilla, small text becomes unreadable.

As I said, mine's working fine since I changed Mozilla's DPI to 96. From xdpyinfo: screen #0: dimensions: 1152x864 pixels (322x241 millimeters) resolution: 91x91 dots per inch

Resolving as a duplicate. This is horizontal misalignment of text, as is bug 80530. If this is not a duplicate, reopen. *** This bug has been marked as a duplicate of 80530 ***