94739 - missing lines of pixels

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[bobbell]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.3) Gecko/20010804
BuildID:    2001080416

When I scroll up on certain pages (articles on http://www.nashuatelegraph.com/
are where I really notice this), the font occassionally is missing a full
horizontal line of pixels.  This is not everywhere, but does occur on multiple
lines as a scroll up. It's as if mozilla just forgot to draw part of the text.

Reproducible: Always
Steps to Reproduce:
1. Go to an article at www.nashuatelegraph.com.  The menu I use works, too:
http://www.nashuatelegraph.com/main.asp?SectionID=25
2. Scroll down some (I use the page down key)
3. Scroll up (I press and hole the up arrow key for a short while)
4. Look for lines where the font has been mangled.

Actual Results:  Text is fairly legible, but a few lines appear as if mozilla
just skipped that line of pixels of the text.  Note that there is no "gap" in
the font; the overall effect is that the font is also a little smaller.

Expected Results:  Display the text correctly, as Navigator 4.76 does.

Comment 1

[Asa Dotzler [:asa]]

layout

Comment 2

[Keyser Sose]

Markign NEW.

Comment 3

[anthonyd]

I cant reproduce this.
Not a table specific bug, reassigning to core owner.

Comment 4

[Christopher Hoess (gone)]

WORKSFORME in recent Linux CVS.  Is this platform-specific?  Reporter, can you
still observe this in recent builds?

Comment 5

[Kevin McCluskey (gone)]

I can't reproduce using 2002012203 build on WINXP.
Resolving WFM.

Comment 6

[bobbell]

I am reopening this bug.  My apologies for not keeping it up to date.  However,
this bug still occurs.  I get it every time using mozilla 0.9.8 and the perl.com
URL above (updated).  I would also like to see the milestone adjusted.  IMHO,
1.2.0 is too far out.  This greatly impacts the usability of the browser.

I've attached a PNG screen capture (moz_scroll_bug.png) of the given URL after
holding the down-arrow key so that you have an example of what's going on.

Additionally, I would like to note that this problem goes away when the screen
is repainted.  If just a portion of the browser window is repainted, just that
portion will be fixed.  I've attached another screen capture
(moz_scroll_bug2.png) of the same problem, but in this capture I used another
window to force a repaint of about half of the browser window.  You should be
able to identify lines that are missing pixels on the left but are correct on
the right.

Comment 7

[bobbell]

Attachment: Example of missing pixels

Comment 8

[bobbell]

Attachment: Half corrupted, half repainted

The corrupted was recreated as in attachment 69720 [details], and then another window was
used to cover up half of the browser window, so that that half would have to be
repainted.  You should be able to see lines of which the left half is
corrupted, but the right have is fixed.

Comment 9

[Andrew Schultz]

this is bug #122577.

Comment 10

[bobbell]

This bug does indeed seem very similar to the description given for bug #122577.
 However, I am unable to reproduce this bug with any of the test cases given
there, while I can reliably reproduce it with the perl.com URL given.

I recommend investigating the bugs together, but not resolving one as a
duplicate of the other quite yet.

Comment 11

[Andrew Schultz]

It's probably related to the specific font / size Mozilla chooses, based on your
font prefs and dpi setting (I was only able to get bug #122577 to misbehave with
a specific font size).  I am unable to reproduce either bug on the machine I'm
at right now...

You might try Ctrl+ and Ctrl- to change the font size and see if that "fixes"
what you're seeing.

Comment 12

[Andrew Schultz]

I am able to reproduce the problem with both URLs.  If I decrease (or increase)
the fontsize here, the problem goes away (same as bug 122577)

Comment 13

[Gyles Harvey]

Attachment: http://www.mozilla.org/roadmap.html

Another bug discussing this is bug #121920

I can reproduce the problem from the mozilla roadmap page:
http://www.mozilla.org/roadmap.html

The second paragraph ("Each milestone ends with a...") gets
corrupted (but the first does not).

As for [e-mail] either a partial of full repaint
(or scrolling with page down not arrow key) "fixes" the problem.

I'm running on:
SunOS xxx 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-5_10
building from CVS mostly.

Comment 14

[bobbell]

I have not been able to reproduce this bug with the mozilla roadmap URL.  Nor
have I been able to reproduce this bug using various font sizes and any of the
test cases in bug 122577.

I was able to get some effects of this bug with attachment 66524 [details] to bug 121920.
 I was also able to reproduce this bug for the perl.com URL with all different
font sizes that I tried, though the effect was more obvious with some than with
others.

Comment 15

[bobbell]

Please see discussion in bug #122577 about explicitly setting the Display
resolution.  This work-around worked for me.

Comment 16

[dmitry]

I confirm this problem with 2002061108 on linux, and I also confirm that setting
the dpi value in preferenced fixes it. However this bug must be fixed asap, I'm
sure it affects many people although not everyone realizes what is wrong - many
people will just get a vague feeling that "fonts are ugly in Mozilla." And of
course not everyone will go to bugzilla for instructions on how to work around it.

Comment 17

[Pádraig Brady]

I've just noticed this for the first time with the 1.1 beta! (2002040813)
I can very easily reproduce it. RH7.3, mozilla default font settings.
I've noticed the missing pixels in all text, including toolbar button text.
Interestingly with the toolbar button "Bookmarks" I noticed once the "Book"
had missing pixels but the "mark" didn't?
I think I just noticed the missing pixel line in a pixel but I'm not sure?

btw when testing this I noticed another bug with text resizing,
where the position rendered in the page changes. Will log seperately.

Comment 18

[Daniel Perup]

It seems work has stalled on this bug. FYI I still see it on Moz 1.1 on Mandrake
9.0 + GNOME 2. The workarounds posted here has not worked for me.

If I can be of any help, let me know.

Comment 19

[Daniel Perup]

...and now I tried Phoenix 0.4, which displayed the same problem. I'd say this
is a fairly big annoyance for me, since readability on many pages is
considerably reduced.

Platform and OS on this bug should be changed to include PC and Linux as well.
Maybe "All" would be apropriate?

Comment 20

[David Nesting]

I see this all the time, and have mostly tuned it out, though occasionally (with
small fonts) it impacts readability significantly.  I see this in all recent
builds on both Win2000 and WinXP on nearly every web page (including this one).
 You just have to scroll around a bit and eventually you'll see a line with a
row of pixels missing.

Strangely enough, I'll also occasionally see a line with an doubled row of
pixels (making the line one pixel taller than the others around it).

I *have* tweaked both my OS and Mozilla DPI settings.  Mozilla is set to 107 DPI
and Win2k is set to 104 DPI.  I'm not sure why they're different, though I'll
try making them the same and see if that changes anything.  (On a related note,
is there a way to tell Mozilla to use "104 DPI" instead of measuring the length
of the line and putting in a length measurement?)

Comment 21

[Pádraig Brady]

I notice this in galeon-1.2.7-7.x.1 also.

Comment 22

[Dean Peterson]

Minor notes regarding comment #13:
The page referred to as http://www.mozilla.org/roadmap.html is now at
http://www.mozilla.org/roadmap/roadmap-05-Jun-2002.html.  

The "second paragraph" is, more specifically, the second paragraph below the
tree management diagram.

Oh, and incidentally, I could not reproduce the issue.  I'm running a 20030402
Mozilla nightly on Windows 2000 Pro.

Comment 23

[Gyles Harvey]

I think it could be specific to particular fonts. Some always work fine, others
show the problem. I have seen this with both Moz and Galeon too.

Comment 24

[Andreas M. Kirchwitz]

Oh, Thank God!

For 3 months I searched the net to find help for that Mozilla bug with the
missing pixel lines, but haven't found anything useful yet. But now I found
this bug... I'm so happy that I'm not the only one with this problem!

Yes, I can verify that this bug exists - but it only happens under certain
circumstances.

I'm using Red Hat 9 (with all patches applied) on several Linux PCs.
Most of them are equipped with all types of Nvidia cards. I use the
"nv" driver included with XFree 4.3.0. Mozilla runs fine on these PCs.

Only one PC (Dell Dimension 4550) has a ATI Radeon 9700 TX. I tried
the Radeon driver included with XFree 4.3.0, and the current ATI driver
from the GATOS project. Mozilla is missing pixel lines when scrolling
(mouse, keyboard). I can verify this with Mozilla 1.3.x and 1.4
(including alphas, betas and release candidates). The bug also occurs
with Mozilla Firebird, so it must be general rendering problem.

For obvious reasons, the effect is worst if smooth scrolling is enabled.
On some pages its not seen at all. Changing fonts, font sizes and DPI
doesn't make the problem go away, but it helps to fix it (or minimize it)
for certain HTML documents.

First time I've noticed this problem was on sunsolve.sun.com and viewing
the report for a patch id (like 109234).

It looks like the problem occurs most often if a page uses more than
one font (like some chars in mono-spaced font, some in proportional font),
and if several font sizes are used (especially if the fonts need to be
scaled to match a requested size).

Since text in Mozilla is unusable on pages where this bug occurs, I use
the evaluation version of Opera to view those pages. However, I'd prefer
to use Mozilla for everything as I really love that browser. If I can
do anything that is of help to find/fix that bug, please let me know!
I'm happy if I could help!

Greetings,
Andreas

Comment 25

[Jacob]

I suggest to change the summary line to 
   "missing lines of pixels in text when scrolling using Arrow Down".

This only happens when one scrolls with "Arrow Down". It does *not* happen: 
    - when scrolling with mouse and scrollbar,
    - when scrolling with PageDown, PageUp, Home, or End.

I see this bug all the time on Windows2000 and in Solaris/Sparc,
including the Moz Win32 build from yesterday and the Netscape 7.1 on Win32.
BTW I see this bug right now on this page while I'm entering this comment.
It's easy to reproduce this on Windows2000. I'm not sure if this bug exists on
Linux.

I'll try now to give here all precise info on how to reproduce this:

1. Use Windows 2000. Set diaplay resolution to 1024x768.
2. Open Moz Preferences->Appearance->Fonts, check the settings:
    Proportional = Serif = 16
    Serif = Times New Roman
    Monospace = Courier New = 13
    Minimum Font Size = None
    Display Resolution = 96
I think those are all defaults.
3. Open page of this very bug:
   http://bugzilla.mozilla.org/show_bug.cgi?id=94739
4. Maximize window.
5. Press <End>,<PageUp>, then hold <ArrowDown> until you reach
end of page. Observe missing lines of pixels in some lines of text.
6. Press <Home>, then press <ArrowDown> ~30 times until you see the 
bug description on screen. You'll notice several lines of text have missing
horizontal lines of pixels. For me, following lines are corrupted:
         line "BuildID:    2001080416"
         line "4. Look for lines where the font has been mangled."
         line "Expected Results:  Display the text correctly.."

Missing pixels are re-drawn correctly when you do one of the following:
- select the mis-rendered line with mouse
- press PageUp then PageDown
- minimize then restore the window

My observation is that those lines of pixels which are blanked are those
which were on the very bottom of the screen between to ArrowUps.

Comment 26

[Andreas M. Kirchwitz]

I couldn't reproduce this bug on Windows yet, but on my Linux box,
the missing lines of pixels happen independently of the way of
scrolling (keyboard, mouse wheel, arrow buttons, scrollbar).

However, I can see the problem best if I use the mouse wheel.

But "OS" and "Hardware" type of this bug should be changed to "All"
as the problem is obviously not restricted to "OSF/1" and "DEC".
It's a general flaw in the rendering engine.

Comment 27

[Gavin C. Flower]

Attachment: missing ,lines of pixels

I'm getting missing lines of pixels using Mozilla 1.5a. I have Red Hat 9, and
I'm using the graphix support built into my motherborad.

Comment 28

[Andreas M. Kirchwitz]

A workaround for this problem is to force the X server's
screen resolution to 96x96 dpi. (For me, it doesn't help
to do this in Mozilla itself).

For XFree86 4.3.0, this can be done by adding

     DisplaySize  337 269

to the "Monitor" section. Mozilla will run fine after this.
Sorry, I don't know a workaround for non-XFree86 systems.

However, the bug is obviously in Mozilla not being able to
handle screen resolutions which are not exactly 96x96 dpi.

Btw, although rendering errors during scrolling are most
common, I've also seen such missing pixel lines in UI elements
like the "Personal Toolbar".

Greetings,
Andreas

Comment 29

[Gavin C. Flower]

Note that the lines of pixels are not compeletely missing.  In the first
attachment (created 2002-02-15 13:02:53), and initial capital letter is intact,
but pixels of some subsquent lowercase letters are missing in the same line of
text.  I found this myself browsing just now, the same symptoms as the first
example png.

I get missing pixels in Linux by simply scrolling down using the mouse wheel.

I have smooth scrolling set.

Comment 30

[Mats Palmgren (inactive)]

.

Comment 31

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

.

Comment 32

[Pablo]

Ive the same problem here, Firebird 0.6.1 and Gentoo Linux. You have already
said all, i also found out that if you select the buggy text it will correct the
line but is very annoying to do that all the time.

Wish someone find out a solution.

Comment 33

[Pablo]

I forgot to mention that it happens always with this web
http://www.noticias3d.com/articulos/200309/socketsa64/1.asp, when scrolling down
as you said some lines (not always the same ones) will have this prob.

Comment 34

[Pablo]

With this one missing pixels are everywhere.

http://www.dvdrhelp.com/dvdplayers.php?DVDname=Philips+701&Submit=Search&Search=Search

I think this bug more important than being NEW since 2001.

Comment 35

[Jacob]

This bug is the same as bug 172162
http://bugzilla.mozilla.org/show_bug.cgi?id=172162

Comment 36

[Joosep-Georg Järvemaa]

Attachment: Missing pixel lines in text

Reproducing:

1) Load page.
2) Hit down arrow button.
3) while (!enough) goto 2)

Comment 37

[Joosep-Georg Järvemaa]

Sorry, there are the details, like:

Build: 20030917
XFree: 4.3.0
KDE:   3.1.1
SuSE:  8.2

Comment 38

[Christian Hamacher]

See also bug 217825 and bug 217313 - possibly dupes.

Comment 39

[Heath Johns]

I just wanted to verify that Andreas' fix (comment 28) works.

Comment 40

[Christian Hamacher]

Oh - wow! I completely missed comment 28 ... and yes, it's working for me as
well! (today's CVS trunk build, Xft enabled, on Linux)

Before, for some reason I don't remember, I had it at "DisplaySize 320 240". I
now changed this to "DisplaySize  337 269" as per comment 28, and additionally
changed the display resolution under Appearance|Fonts to "System settings".

Since then, the problem went away completely for me.

Comment 41

[Pablo]

Using Firebird 0.7(gtk2+xft) and changing to "DisplaySize  337 269" also works 
for me. 

Comment 42

[Wout.Mertens]

I just noted that I can easily trigger this bug under X by taking a small window
and waving it over the mozilla window (with opaque window moving). A great site
to do this on is http://www.slashdot.org, especially the columns on the right
and the italic text of the stories.

This forces a lot of redraws from mozilla (if saveunders and backingstore are
disabled), which brings out the bugs more easily. You can really see the pixels
go missing and move around. It's horrible :)

I was even able to reproduce the bug on gtk2 builds, which seemed to have less
of a problem. To do this, I first had to use a font where the antialiasing
doesn't work, though. I selected "gothic".

Ok, so now that we have a reliable test case (works 100% of the time for me),
let's get it fixed :)

Comment 43

[Tristan Miller]

I believe Bug 172162, Bug 215759, Bug 217825, and Bug 217313 are all duplicates
of this bug.

Also, the "test case" to reproduce the behaviour described in Comment #42 does
not work for me.  I can't make the fonts garbled by dragging a window overtop
the Mozilla window.  The bug occurs for me only when scrolling.

Comment 44

[gerwin]

I have the same problem with the table written below, with only one tr (row)
there are no problems, but with multiple tr's (rows) there are a lot, missing
lines etc. So I suggest you to copy everything from <tr> to </tr> and past it a
few times in the table and check for yourself. In microsofts browser everything
is oke, so it must irritate you guys hehe. 




<TABLE width='100%' border='1' class='table'>

 
    <TR> 
	<TD colspan='4' height='30'><H2>Titel</H2></TD> 
    </TR> 
    <TR> 
        <TD colspan='4' background='../images/texture.gif' height='45'><P
align='right'>Page:<SELECT name='pagina'><option value='1'>1</option> 
            <option value='2'>2</option></SELECT></P> 
       </TD>    
    </TR> 
    <TR> 
        <TD width='15%' height='100' rowspan='3' valign='top'><font
size='4'><b>naam</b><BR> 
        </font> 
        Avatar<BR> 
        <B><font size='1'>Short text</font></B><BR> 
        <BR> 
        <BR> 
        <font size='1'><B>Posts: </B> 18<BR> 
        <B>Location:</B>Norg<BR> 
        <B>Registerd:</B>29th of October 2003</font> 
        </TD> 
        <TD height='23' width='80%'> <font size='2'>By Guldan - Thursday 02nd of
December 2004 04:29:43 PM</font>&nbsp;</TD> 
        <TD>Include rechten module </TD> 
    </TR> 
    <TR> 
        <TD height='100' width='80%' colspan='2'>Topic Titel</TD> 
    </TR> 
    <TR> 
    	<TD width='70%' colspan='3' height='20'> 
    	<FONT size='1'>Signature</FONT> 
    	</TD>  
    </TR> 
    <TR> 
    	<TD background='../images/texture.gif' colspan='4'>&nbsp;</TD> 
    </TR>
 </TABLE>   	

Comment 45

[Brett Donald]

Shouldn't this bug depend on bug 63336, rather than block it? Bug 63336 is the
master bug for all pixel rounding problems.

Comment 46

[Giuseppe Ghibò]

I get the same problem also in current mozilla 1.7.12 as
well as firefox 1.0.7, either with xfs or Xft fonts
(see my screenshots on bug #198675)

The problem of missed pixel line seems arising when Xdpi is not the
same as Ydpi, e.g., using:

xdpyinfo |grep -i "dots"

gives

  resolution:    90x96 dots per inch

Comment 47

[Tristan Miller]

Giuseppe Ghibò, are you sure that the problem occurs only when Xdpi is not the
same as Ydpi?  The problem occurs for me as well, but my resolution is 75x75:

[psy@port-3108:/tmp]$ xdpyinfo |grep -i "dots"
  resolution:    75x75 dots per inch

Comment 48

[Giuseppe Ghibò]

x Tristan Miller: I got that on my Matrox G450, G550 as well as on ATI X300
desktops, with basically xorg up to 6.9cvs (but I was getting it since a long
time, 2-3 years at least).

But I don't remember to have seen it on my notebook ATI 7500 mobile based
where I have xdpi=ydpi around 120dpi, maybe it's a coincidence?

Comment 49

[Giuseppe Ghibò]

I wonder if could be related to the fact that also I've a wheel mouse on
all the machines where this problem happens.

Comment 50

[Gábor Stefanik]

I bet this is now fixed thanks to the unit fix, but I don't have a working Linux box right now. Could someone check it out and update the bug status accordingly?

Comment 51

[Reid D Rivenburgh]

I haven't been following this closely, but: I am using Linux, I'm using firefox Build ID: 2007091104, a desktop PC with a GeForce FX 5700 video card, and a wheel mouse.  I am unable to reproduce the problem on a random article at http://www.nashuatelegraph.com/ or the perl.com URL.  I even bumped the font size up a few times.  I vaguely recall seeing these symptoms at one point, but not recently....  Hope this helps.

Comment 52

[Gábor Stefanik]

I think it's WORKSFORME then. I also wasn't able to reproduce this bug in Firefox 3.