217825 - Scroll Down (Cursor / Page Down) drops one row of pixels where the visible area should join

Status: NEW

(Core :: Web Painting, defect)

Description

[Gerhard Hossinger]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Scroll Down with curser keys (Curser Down, Page Down) or Mouse Wheel Down.
(Scrolling by the help of the mouse and the scroll bar always works.)
(I have never seen this error on my Windows platform).

The problem may be dependent on Font Size and Text Zoom, but when/where 
this error occurs it is reproducable.
(Or maybe in a bigger font size you just don't miss a row of pixel 
as in a small font when a horizontal line is missing.)

Examples where to test:

http://members.allstream.net/~fcsoft/
Zoom 100% and scrolling down using curser key corrupts the shown text.
but Zoom 120% seems to work (at least I did not see any error).

http://www.theregister.co.uk/ 
Zoom 100% shows the error
Zoom 120% shows the error 

I also opened http://members.allstream.net/~fcsoft/ in the Composer window 
where scrolling with the Wheel Mouse gave a similar error.


The pixel row which is dropped is the row which is just below the visible 
area of the screen.
When scroll down shifts the visible screen upward and then should join 
with the next screen section then the upper most row of pixels seem to
dissapear" at the joint.

Work around: "Refresh" the screen by ALT+A (Select all) and ESC.
You can see where the corrupted font is corrected by this refresh.

Possible reason for this error:
- wrong offset for move of "bitmap" or renderering of next section

- some rounding error when calculating where to join the visible area 
with the next section of the web page.



Reproducible: Always

Steps to Reproduce:
1. Open http://members.allstream.net/~fcsoft/
     or http://www.theregister.co.uk/ ...
   in the Browser or Composer

2. scroll down so that a lowest line is shown partly (lower part of charactes 
not yet visible).

3. scroll down further using Curser / Page Down or Mouse Wheel
   (Composer: only Page Down or Mouse Wheel possible)


Actual Results:  
One row of pixels missing at the joint of the visible areas 
of the web page.
If this row of pixel is through a text line then the font looks corrupted.
Verify by pressing ALT+A and see that the font is corrected (refreshed).



Expected Results:  
Scrolling using Curser Down, Page Down or Mouse Wheel Down should always show 
the fonts correctly.

Scrolling using mouse and scrollbar is already working nicely and I expect 
the same result with curser keys.
Scrolling with curser keys under Windows is also working nicely.


I have seen this problem also in Mozilla 1.0 (Linux) and I guess 
also Firebird has the same bug.
(but I use Firebird only on my Windows box, so I cannot say for 
sure how it works on Linux).

Comment 1

[Gerhard Hossinger]

I just experienced that the same error (drop a row of pixels) even occurs 
when scrolling upward using Curser Up, Page Up or Mouse Wheel Up.

Comment 2

[Christian Hamacher]

Could you have a look at bug 217313? It seems that the symptoms are very
similar, even though this other bug doesn't only happen at the border of the
viewable area.

I can not reproduce the problem on allstream, but I can occasionally reproduce
it on the register page.

The register also exhibits the behavior described in bug 217313 where
highlighting parts of the text makes the highlighted text shift a small distance
up or down. This is probably what 'fixes' the corruption if you highlight the text.

Are you using an Xft build? Are you using 'smooth scrolling'?

My system:
RH 9 Linux, XFree 4.3, fontconfig 2.1, current Mozilla CVS build with Xft,
smooth scrolling enabled.

Comment 3

[Gerhard Hossinger]

Attachment: list of files (ls -l -R)

I looked at bug 217313 and the description there sound familiar.
It should be the same error, either manifested in a different way 
or just described from a different point of view.

BTW, when scrolling through the bug description, I also saw 
corrupted charactes. easy to see when the font (kind of courier) 
has thin lines and the upper line is missing / damaged.
The report 217313 states the small shift (by one pixel) when 
the screen is re-displayed (and thus corrects the corrupted 
fonts on the screen.
When scrolling with all highlited (Alt+A) then also the 
highlighted will get corrupted since it is just the same font  
displayed with a different foreground and background color)


My (home) PC runs a Mandrake 9.0. with KDE desktop 3.0.5a and 
Xfree 4.2.1-3mdk.
My Mozilla is installed from 
"mozilla-i686-pc-linux-gnu-1.3-sea-tar-gz 1.4"
(Thanks to the download manager remembering my download).

see also text file "moz14.txt" with list of files (ls -l -R).

Comment 4

[Gerhard Hossinger]

Attachment: example of corrupted font display

You can see the white lines in the highlited (marked) text on the upper right.
These white lines show where the displayed font has been corrupted.
example of corrupted font display

Comment 5

[Gerhard Hossinger]

Attachment: example #2 of corrupted font display

You can see the white lines in the highlighted (marked) text on the upper
right.
These white lines show where the displayed font has been corrupted.
Interestingly, these are rectangles of correctly showed text (font) 
which occurred by the overlay of the screen dump window, which caused the 
font to be re-displayed on the areas (rectangles) where the window(s) 
has been hiding the mozilla screen.
You can see that the corrupted charactes are partly shifted (upwards) 
by one pixel row, where on the other side of this shift one row of 
pixels are dropped.
I also saw on certain URL's that this problem would only occur when 
you increase Text Size (Ctrl++), but not in the original text sise.

I think, any scrolling that "jumps" (in opposite to smooth scrolling) 
shifts and displays junks of pixel-rows (characters).
The row of charactes iitself must be created by the font system into 
a working-buffer, and in joint-area partly displayed.
The question is, how is the the hight of the character box calculated? 
Is it the application (Mozilla) or the font system?
And I guess, (because the different measurements like points, pixel, etc.)
there is some kind of floating point calculation involved.
So there could be a problem with the rounding of the floating point result.
The problem might be so simple that it depends if the provided value(s) 
give a positive or negative result, and before the rounding the result 
is not converted to an absolute number.
But that is just a guess...

Comment 6

[Joosep-Georg Järvemaa]

This is dupe of bug #94739, I think...

Comment 7

[Christian Hamacher]

I can confirm this on current Linux CVS trunk builds - in fact, I have seen this
behavior for quite some time now.

The degree to which this appears depends on the font, font size, etc., but no
matter the configuration, the problem never entirely goes away.

Also see bug 217313 and bug 217825 - possibly those as well as this bug are all
duplicates of bug 94739, as was suggested in comment #6

Comment 8

[Christian Hamacher]

Over in bug 94739, a workaround was posted (look at comment 28 there). This
fixed the problem completely for me - if it also does for you (obviously, the
workaround only works for unixoid systems, since you need to modify your X
config), this is one more indication that this bug is a dupe.

Comment 9

[Christian Hamacher]

Confirming based on large number of duplicates, similar bug reports, and
comments in those.

See the meta bug 134942 with a long list of comparable '1-pixel-rounding' errors.

Platform->All
OS->All

Comment 10

[Christopher Hoess (gone)]

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

Comment 11

[Patrick]

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, ...?