Text seems to be squashed to the unreadable state when scrolling down then up with either the keyboard or the mousewheel.

The same used to happen to images I seem to recall.

I've been seeing this too for a couple of weeks with Solaris build 20020115

Over to layout.

With the Jan 3Oth build (2002-01-30-12), I can't seem to reproduce. Reporter, can you provide any additional steps to reproduce ? Tested under Redhat 6.2.

worksforme, using winnt4, 0.97 release. however, the text at http://www.macromedia.com/shockwave/download/alternates/ is still squashed -- but that's without scrolling.

How I caused the render problem =========================== Viewing the supplied URL, I scroll down twice with the mouse wheel, then scroll back up again. The part of the page that is "cut" by the top of the viewing window within the browser is the section that becomes corrupt in the way that is shown in the image. Hence on scrolling back up, there are two areas that appear corrupt. Not suprisingly, giving another window the focus (covering the corrupted text) causes a refresh and the text appears as normal. This last behaviour is random however, as in Gnome, cycling through the windows (as in Windows bringing up a small dialog with icons of the windows), causes text at the border of this dialog to become corrupt if a page in Mozilla is sitting underneath (before and after images attached).

I can't repro this on win98 or win2k, and I also tried on the mac -- this may be a linux only issue

this is a minimal testcase. if the <div> or <p> tags are removed, everything works fine. fonts sizes other than 10pt do fine also. a) To reproduce, make the window small enough to scroll. Scroll around. b) Alternatively, simply drag a window over the text. Sometimes the damage is not noticable, but if you refresh, you will see it change.

Taking this bug

I've been seeing bad text scrolling on various CNN sites for a long time, since at least 0.9.6. It drives me absolutely nuts, since I have to do page up/page down all the time to refresh the display. The attached image results from: 1. set browser window to about 800x700 size 2. visit http://sportsillustrated.cnn.com/olympics/2002/ice_hockey/news/2002/02/15/sweden_canada_ap/ 3. press the down-arrow key 18 times

This bug seems very similar to bug #94739. However, the bugs appear to show themselves in different test cases. I am able to reproduce bug #94739 reliably, but I have had no problems with any of the test cases given in this bug report.

Bulk moving Mozilla1.1 bugs to future-P2. I will pull from this list when scheduling post Mozilla1.0 work.

Confirming this bug with 20020227xx trunk on Mandrake 8.2 cooker Linux.

I can confirm this on 0.9.8 (Mandrake 8.2beta3). Previous build (0.9.7) has no such problems.

this "off by one" misrendering of fonts/images after is still visible with 0.9.9 and newer (on different recent Linux systems). This bug is "popular" among many of my friends. This is probably some rounding problem somewhere in "layout", probably at least two of them, because it affect mostly scrolling but sometimes pure loading simple webpages with simple default fonts shows this behaviour. Getting rid of is is a bit tricky - re-scrolling the pages or selecting affected text (sometimes you select one and another text gets off-by-one misrendered, so you select the next line and previos gets the error.) I will try to search all similar bugs already reported to bugzilla to find duplicates etc.

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

This my be related, or a symptom of the same bug as bug 83289. It is related to dpi. I can workaround the problem by setting Display resolution on Appearance/Fonts to 96dpi, instead of 'System setting'. Using Mandrake Linux 8.2 I am running at resolution of 1280x1024 (however, changing browser window size does not have an effect). BUT: My X server reports resolution 90x96 dpi. GUESS: Perhaps Mozilla code assumes that X resolution == Y resoltion somewhere? This may be true on Windows, but not under Linux.

Yes, this workaround also works for me. I've got 19"/1280x1024 and Xserver reports 90x96. When I turn "system settings" to "96dpi", text is renderred without missing horizontal lines. See also bug 131107, bug 129400, bug 80530 (and cca 10 others, see comments) ... and finally bug 63336 (could be the source of this problem). Some screenshots of text are also at http://Xtrmntr.org/ORBman/tmp/hlp/

Setting the Display resolution to 96 dpi also works for me with the test cases I've reported for bug #94739. I am uncertain what my Xserver reports (is there a standard way to query this?).

'xdpyinfo' will tell you the dpi (and a lot else :)

Thanks for the pointer Gavin. xdpyinfo reports for both of my screens: dimensions: 1280x1024 pixels (280x236 millimeters) resolution: 116x110 dots per inch As mentioned, setting the display resolution to 96 dpi (instead of "System default") seems to work.

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

The attached image shows my browser after visiting http://www.cnn.com/2002/HEALTH/diet.fitness/04/11/couch.potato.pill.ap/index.html and scrolling down 7 times. Browser size is 823x740 according to xwininfo; this matters (different sizes fail to show problem, or show it elsewhere). Bottom line is that setting my Font settings to 96dpi does improve the situation, but the problem is definitely still present in some form. Ordinarily, xdpyinfo reports 90x89 dots per inch.

Did you try restarting Mozilla after changing the font dpi setting? I found out you have to... But since you run in different dpi, it may not help.

Ah, now things seem to look right. Restarting after changing the DPI setting to 96 worked. I hadn't thought to do that because, even without restarting, changing the setting has *some* effect...

I think this bug should have a release note for the next milestone(1.0). The workaround is very effective, but since most people never fool with their font dpi they are unlikely to figure it out.

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