This happens both on Solaris 8 x86 and Solaris 7 SPARC, both with Mozilla 1.1. On pages that have a lot of text, when I scroll down to read, lines get rendered with missing scanlines. The example page above uses <font face="Arial, Verdana, sans-serif"> It makes no difference whether I add the a TrueType directory to the font path.

Added attachment. In the line " Jamaican Prime Minister " you can see that the scanline passing through the centre of the letters is missing, so that the horizontal parts of "a"s and "e"s is not visible. In the line "The UN rapporteur for Burma", it is the scanline at the very bottom of the text that is missing. Lastly, in the line " European reinforces controls", it is towards the top of the letters that there is a scanline missing,].

WFM, Mozilla 1.1b, Solaris 8 on Sparc. Reporter, does this happen with the latest nightly?

The latest nightly bombs just afer the main window is displayed, printing X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 66 (X_PolySegment) Serial number of failed request: 1160 Current serial number in output stream: 1175 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 66 (X_PolySegment) Serial number of failed request: 1162 Current serial number in output stream: 1176

Tried with Solaris x86 nightly build: problem is still there

This bug has been around for a while, but I couldn't find another entry. It doesn't only happen on sans-serif fonts: See e.g. http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=patch&doc=9_Recommended.README The problem occurs on the upper and lower edge of the window when scrolling text into the window. I've seen similar things happen with images too, by the way. According to the n.p.mozilla.unix newsgroup, this might also occur on RedHat.

I've had the same problem on both Gentoo and RedHat linux. The Gentoo Moz is: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021020 I'm seeing it on many pages I view - including the bugzilla pages of mozilla.org, slashdot.org and many many more. Created attachment viewing slashdot.org. It seems that if I mark the badly rendered text with the mouse it will correct and rerender properly.

I have this problem too on both Mozilla 1.1 and Netscape 7.0 using Slackware 8.1 KDE 3.

Same problem with RedHat Linux 8.0, mozilla 1.1 - 1.2b & Galeon 1.2.6. It seems that this bug is incorrectly set to be Sun Solaris specific. Could someone please change that? rgds, lasse

Been seeing this with rh7.2 (up-2-date'd) in Galeon and Mozilla 1.0.1 for quite a while. Thought it was probably video card. Replaced with new different type of card and still see the problem. The attachments provided above look just like the kind of text distortions I see. Definitely not just a solaris problem!

This problem is still there using the current 1.3b from today (2003-02-03). Changing the platform and os to 'all' by popular request. To everyone on the CC-list: which GTK and glib library is Mozilla using? bash-2.05$ /usr/sfw/bin/gtk-config --version 1.2.10 bash-2.05$ /usr/sfw/bin/glib-config --version 1.2.10

This bug also extends to images, not just text. Example: http://www.dpreview.com/reviews/nikond100/page17.asp Scroll down this page slowly, untill you see the picture below the word 'Night Images'. Now move your pointer over each of the images, and you will see them each become one pixel taller (extending downwards) all of a sudden.

I noticed the problem only happens when I scroll a line at a time. If I page down everything works.

I agree, single line scrolling triggers it more. Its seems that when a text line is bisected by the upper or lower window border and then scrolled into view it often (but not alway) gets distorted. When you page up and and then down, the distored line is repaired. Also, I think I see it less often when I set "allow document to use other fonts" in the fonts dialog.

This happens frequently e.g. on one of Austria's largest online newspaper site http://www.derstandard.com For small font sizes, the text is sometimes close to unreadable. This is highly visible and leaves a rather bad impression. One of the things that people here complain about most often to me when using Mozilla.

With this testcase, I only ever see the problem within the first div (i.e. before the horizontal ruler). The only difference is that the first block uses line-height: 17px and the second one line-height: 16px. Further testing seems to indicate that the problem only occurs with odd px values for the line-height attribute, never even values.

Making this block bug 134942, other bugs dependent on bug 134942 might be related or even DUPes?

This seems to be related to the display resolution settings (in preferences->appearance->fonts): this was set to "system settings", but when I change to 96dpi, I cannot reconstruct the problem in the testcase anymore. When I set it to 72dpi, I see the problem, but less pronounced. Switching dpis relyably makes the problem appear and go away.

When I render the testcase with three different dpi-settings in three tabs and then switch between them, the font sizes appear *exactly* the same, but with the settings that cause problems, the vertical whitespace on top of the page seems to be just one pixel larger.

the image that is included repeatedly in the html-file consists out of black and white horizontal lines, so the image appears normally plain grey. you can see that the images are also affected from the bug: single horizontal white or black lines (two pixels high) appearing on the screen because single rows from the source image are dropped during srcolling. if you select the affected images or text-lines all is repainted correctly. the corruption is generated at the top and bottom of the visible part of the page. a single pixel row of the whole page is dropped. it is irrelevant which scrollmethod you chose, the bug is always there. but smaller scrollsteps leads logically to more rowdropping, so you can recognize it easier. i recognised this bug through several mozilla-versions (0.9 - 1.4) on different flavors of linux (redhat, gentoo).

It's been a while since the last entry to this bug. Anyone else than me still experiencing the problem? I noticed a strange thing. Trying out Gnome 2.6 just now it seems that this bug is not in effect there. Yet it's still in effect under WindowMaker. Perhaps this is an issue in the Mozilla/Windowmanager integration? Could somebody please verify/deny this? I'm currently running Firefox 0.8 under WindowMaker 0.80.1. The Gnome desktop is 2.6 using metacity as window manager.

The problem is certainly still there with Gnome 2.0 and Mozilla 1.6 Solaris x86. I'll check with Mozilla 1.7 SPARC at work tomorrow.

I've now been using Mozilla 1.7 for a couple of days, and haven't yet been able to reproduce the problem.

I am seing this too with FireFox 1.0 (Linux/Suse9.1/KDE3.3.1). In an attempt to put things together, I am listing here bug reports that seem related to me. Sorry for not doing more analysis (and reading all the comments of all bugs listed here) or for the bugspam but I really think this linking might be useful. Please note that this bug is listed too (as I put the same in different bugs). bug 172162 Linux bug 174977 All (was Solaris) bug 199840 Linux bug 211704 Linux bug 215759 Linux bug 217336 Linux bug 217825 All (was Linux) bug 228808 MacOS X bug 248799 Linux I built this list by searching for scroll and font in the comments from newest to oldest going up to the first one of this list (feel free to search further) and I might have missed some. I put the OS as it seems there is a link between them: is it due to the usage of a common deployed library, a bug in an OS' library, ...?

I think this is fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090420 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090420041629. So, fixed then? (Screenie of what I see follows)

I think that this can be closed - I haven't seen this problem for some time (though this could be due to OS upgrades etc.)

Duplicate of bug 172162?

Yes, this does seem to be a duplicate of 172162