version 0.9: When scrolling the page, the browser will intermittently shift a line of rendering either up or right. I don't know if there is a specific page structure needed to reproduce this bug, but it happens on many web sites (slashdot, for instance). This only occurs with text, and seems to only happen while scrolling down with the keyboard's arrow keys, not with pagedown, and not with the scrollbars. Could a high (i.e. maximum speed) keyboard repeat-rate be triggering this? Also, if I select the text, or otherwise force a repaint, it gets properly redrawn. I'm pretty sure that this also occurs on Windows, but I'll have to verify that.

I am seeing the same thing all the time with 0.9.2 milestone and have for several versions now. I can usually reproduce it by mousewheel or arrow scrolling on the following page: http://news.bbc.co.uk/hi/english/world/ PgUp/PgDown/Space and scrollbars do not seem to have this problem. I am running: Redhat 7.1 Ximian Gnome 1.4 XFree86 4.0.3 on a GeForce2 GTS (Nvidia driver) One other unusual condition: running Fontastic font server (from WordPerfect Office 2000) in addition to xfs The artifacts usually occur in the same position on the page. I.e. I scroll with mousewheel and get an artifact. Scoll with scrollbar to get rid of it. Scrolling around with the mousewheel again gives the same artifact in the same place.

You just reminded me that I (stupidly) forgot to include the vital statistics on my machine. It is: Redhat 7.1; kernel 2.4.5 XFree4.0.3, nVidia-supplied driver, v1.0-1251 (geForce2 GTS) I am not running the WP font server. My machine has 2 processors which might have a bearing. I suspect that this problem has something to do with the X server or video driver. I tried reproducing the problem by using the Exceed server and a RH7.0 client, but the bug did not manifest. I'll experiment with using the XFree nv driver, and perhaps XFree 3.x.

This seems to be dup of bug 63336 (see also bug 16200). You can try if setting display resolution (Prefs: Appearance: Fonts) to 96 dpi helps.

Hey, that works for me. I had switched the resolution to 100 dpi at some point and switching back to 96 definitely fixes the text display problems and also some single-pixel white lines that were cropping up in some images. Thanks!

Upgraded to milestone 0.93 and this problem seems to be back. I've tried setting DPI to "System setting" and that doesn't help. I'm getting single pixel errors in text and images.

I also see this on 0.9.4 on : WinME ATI Radeon 32MB DDR (driver 4.13.7115) 120dpi fonts at 1024x768.

Need a reduced test case.

What do you mean by reduced? I'm seeing this happen only on one systems -- others don't reproduce. Maybe its a thing with my video drivers, maybe my font sizes, etc. Would you like me to post a screenshot? I'd be happy to provide more info/assistance. (Short of installing BackOrifice in my box :) )

I can't help with a reduced test case, it never happens (for me) in exactly the same position, and rarely (never?) on simple pages. I can almost always reproduce it though by going to Slashdot on loading a page in nested mode (produces a long page with semi-complex layout) and scrolling down a bunch of screens. I'm getting the bug in 0.9.3 (and earlier), I'm running Win2k SP1 P3 600 (OCed) on P3V4X 512MB Asus GeForce 2 w/ nVidia drivers. 20.x or something fairly new. (Doesn't say in the properties, lists it as 5.12.xxx)

I'm not seeing this anymore on 0.9.5 under the conditions I listed in my earlier notes. I don't think I've seen it for a while but didn't notice before that the problem is gone. Perhaps you guys should try 0.9.5 and see if it still happens.

Still present for me on 0.9.5 on both my Windows ME box and my RedHat 7.2 box.

not a table specific bug, reassigning to core owner.

With build 2001121808 I see this in the regular text of slashdot now (when scrolling with the mouse wheel and then stopping). Previously it was in the headings. I've also seen this in mail with this build. Damn hard to reproduce though,

I am seeing this in 20020111 (Linux Mandrake 8.0) especially on http://slashdot.org . I've noticed that if you highlight the problem text then it magically cures itself until you scroll it off and back on again.

Notice that a line has "run" on the left of the roundered box edge

Scrolling with the arrow keys/mouse wheel helps to show this bug up because the page is not entirely blanked/refreshed in one go. Anything that causes mozilla to redraw the page clears up the problem. I am using Truetype fonts with mozilla (MS Verdana is being used on the /. page). My distribution is Linux Mandrake 8.0 Intel. I am using XFree 4.0.3 with the Nvidia drivers (I have a geforce 1). The drivers auto detect a resolution of 72dpi with my current monitor. I can try testing with the default XFree 4 drivers if people think it will help...

Problem is mild but occured in a window of 800x600 by scrolling from the top to the bottom of the testcase with the down arrow key.

Taking this bug

Could be related to bug 63336, but bug 87738 is probably better for addressing the original problem.

Adding bug 97861 to the list of possibilities

I just wiped my profile and started from scratch with 0.9.8. When I did this, I reintroduced this bug (it had left me). I noticed it on the article icons on Slashdot. I fixed it by switching font resolution from "System" to "96 dpi". My system details are in an earlier comment (#2). I have not noticed any problems with text, only with some images. An additional note: I installed Wordperfect 2000 in the past which has its own type manager in addition to XFS. It's possible this affects the situation.

I see this issue w/ 0.9.8 (build ID 2002020516) on Solaris, so it's not a Linux-specific bug. And I don't believe I'm using any of the special font handers the Linux users are -- just whatever comes with Solaris 2.8. I haven't tried setting DPI to 96 yet.

Just to clarify, it turns out I was using the standard XFree86 font server, NOT the special one that comes with Wordperfect so I think we can rule out freaky font servers.

OK, I'm setting Plat/OS to All/All, because I see this on windows 2000 (0.9.8, dpi=96, system dpi=125). I think it's very likely that one of those "rounding error" bugs is the culprit. However, I don't understand the internals enough to just go ahead and mark this bug as a dup (probably of 63336). My vague and inaccurate impression is that this bug is more common on complex pages, like slashdot. It still occurs on simple pages (like this bug page), just less often.

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

This behavior appeared upon upgrading to 0.9.8 on my home computer. I haven't seen it on various other copies of .9.8 that I am using, so it is something specific to this setup. Around the time I upgraded mozilla I did a general update (using debian testing + ximian), so other things may have changed around that time as well. It appears in both mozilla and galeon. If there are any specific things to check I can do that (and am quite willing to), but unfortunately I have no idea where to begin looking to figure out what is going on here. Note that changing the dpi settings did not fix this for me, as it did for a previous reporter. I also do _not_ think this bug should have a low priority - for those who experience this (and it seems fairly cross platform) it is a very annoying visual bug. But of course I have no idea how to fix it so maybe I shouldn't talk :-)

I have to agree w/ poster 28. This occurs for me on Linux and Win2000 machines. Co-workers that have noticed it have scoffed at the browser with quotes like "Well IE doesn't do *that*". This should not be a low priority issue. Its easily as serious as any deviance from a standard.

about to attach paired xmag shots - one of the rendering bug in action, one of the same section of the page when rendered 'correctly' (i.e. after highlighting). These shots are useful for several reasons: - I went to some trouble to make sure that they lined up correctly; you can easily flip back and forth between them and see clearly all the differences that appear. - They demonstrate that the problem is not just text - it is most noticable in text, but appears in images, as in the left side of a slashdot headline which is shown here. This bug is almost certainly a dup of 87738 (or that one a dup of this), but many of the posts there seem to be under the belief that the problem is entirely font-based. - They show an example of several strange and related things going on at once. There is an entire line which shifts a pixel, and this phenomena is really only noticable under xmag. Now if only someone with the knowledge of the layout code was paying attention to this bug... :-)

lined up with previous attachment by the vertical bar on the left, and the top of the green area.

Can you tell I don't like this bug? First of all, I think I spoke in error earlier: changing to 96dpi apparently fixed the problem, but only after restarting mozilla. Switching back to system causes the problem to reappear. I have come up with a reduced testcase and and a mechanism that (at least for me) allows at will duplication of the visual error. Please post if this works for you as well (assuming anyone at all is listening). To reproduce the bug, on a page that can induce it (more about this later, but slashdot comment pages and my test case which I will post shortly should work), open a new window and move it so that a window edge, horizontal or vertical, is covering some text. It's best for the edge of the window to cross through a character that if it's glitched is noticeable, 'e' in most fonts works for me. Then either move the window away, or shade it, so that some of the page is uncovered. You should see that portions of the text have slid to the left. Highlighting will cause the text to be redrawn correctly. This is helpful to look at in galeon: when you refocus the window whatever redrawing is needed for the correct version gets done, so I see large portions of the text move at once. Mozilla doesn't seem to do this; you need to highlight to get it to redraw. I arrived at a test case after much suffering with code produced by slashdot (it would be educational for some of the people who write slashcode to do something like what I did, I think). It consists of a table with a single cell. The cell has the attributes 'width="99%" align="center"'. Remove either of these and the problem goes away. Changing the alignment to either left or right causes the problem to go away. Changing the width to 100% causes the problem to go away. I imagine that some other percentile values of width would show the problem, though I didn't test that. This looks like a rounding error in that in two different pieces of code which are used for the same purpose (?!?) the rounding is performed differently, or the same piece of code does the rounding differently under different circumstances.

as noted before, the important part here are the two attributes of the table entity. To get the problem to show on this test case (assuming it shows at all on your computer) see my previous comment. If this doesn't work for anyone who has observed this bug on their system, please let me know - I have no way of testing this except on my computer at home.

I get what appears to be two different but very related problems. I'm using mozilla 0.9.9 and have a screen resolution of 1600x1200. First if I have the horizontal size of the Mozilla window at or above 1382 I can get 1 pixel shifting when slashdot loads, actually slashdot starts out correct but near the end of the rendering process the stuff gets shifted. Attached is an animated gif of the problem.

I'm using mozilla 0.9.9 and have a screen resolution of 1600x1200. This is an example of the 1 pixel shifting that occures when I scroll around the web page, this shifting happens when the horizontal window size is 922 pixels or larger.

Bug 134638 is probably a dub of this

This bug has been around forever, and is probably also related to all the other 'off by 1 pixel' scrolling bugs (like the 'white stripe', and 'extra row of pixels' bugs - which seem to be fixed lately). For what it's worth, it's not the single distorted line that's affected. What seems to be happening is that the top 'half' of the window is shifted relative to the bottom 'half', and the two halves just happen to meet on the affected line of text. It's gotta be related to the fact that when you scroll, part of the window is simply scrolled, while the other part is repainted from scratch. The two parts are just not in horizontal alignment. Yes, it's a 'trivial cosmetic issue'. No, it's not unimportant. It's probably the most visible, obvious bug that the unsophisticated user (read: all those AOL users that are about to come on board) is certain to notice. And it screams "unprofessional". Plus - it's easily reproducable, so it ought to be fixable.

An alternative for 1.0 would be to default to either 72dpi or 96dpi, and maybe label 2system setting" as experimental. For the record, I've seen this at home with 73x73dpi and at work with 90x89 dpi, both taken from xdpyinfo (mandrake linux 8.*, xfree86 v4.2).

Work in progress - Align all frames (x,y,width,height) on pixel boundaries when

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

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

nsbeta1+. To get the Align frames for non 96DPI setting on the branch only. I don't think we should check this fix in on the trunk. We need to investigate a better solution.

is this related to (or dup of) bug 120918 or bug 87738 ? Has anyone seen this problem in a post bug 120918 fix (after 2002-04-12) build?

I'm seeing it bigtime, build 20020424 linux-i686 It seems to arise more with mouse-wheel scrolling. When I select the text it goes away. Here, I'll post some screen shots.

I see the exact same thing as Brian, i'm using 20020417 (rc1). I've tried every possible DPI setting and it does not change the behaviour at all. I think this bug should be raised to a higher severity. Small text becomes unreadable with this bug. I constantly have to select all text on the page to make mozilla redraw it correctly so I can read it.

Just a quick note to those looking at this page for a workaround to the bug: A few have argued that the workaround of changing the DPI setting doesn't actually work. You have to set the display resolution to any *anything other than* System Setting and then *restart Mozilla* for it to take effect. Then, you will probably no longer see the error. (But it's still a bug :P) If you still see it after you've restarted (Windows folks, make sure Mozilla is completely removed from memory before restarting) then by all means make a comment and tell us a bit about your setup.

Ooh, wonderfull. When I restart mozilla at 96 DPI it works. I've had this problem for a year or something, and now no more. When you change the setting the complete window is redrawn, making you believe the change was applied, but you have to restart. If this bug is not fixed before 1.0 maybe the system setting (and custom setting) should be disabled or at least the default value should be set to 96.

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

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

This should get higher severity since it makes webpages with small fonts completely unreadable. I think it is also one of the more embarrassing bugs to have in 1.0 - people will say "look, mozilla cant even render fonts correctly when scrolling". The very least to do for 1.0 would mention the workaround from comment #53 in the release notes.

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

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

The workaround (setting the DPI explicitly instead of letting it use system setting) has been working nicely for me -- I used to see this bug constantly, and now I never see it. My system dpi is 101, I don't see the bug when I use 96. So apparently we can't deal with dpi settings that are a little off from the ones we understand, 72 and 96? A fix for that seems fairly straightforward: when we're at "use system setting", round to the nearest dpi setting we do understand. Wouldn't that be an easy fix that would cure the bug for everyone who's seeing it?

I reported bug 121920, which seems a bit different from most of the reports here. I see a horizontal error (the line of the error is horizontal), but most people here seem to be seeing vertical errors. However, comment #49 here shows exactly the same error as I see, and the workaround (to change the DPI from system setting -- 90 in my case -- to one of the explicitly listed ones) gets rid of the symptom, so perhaps it's the same bug anyway. I've never seen it on slashdot, but enough sites have this problem that it's far too annoying to go unfixed (or not mentioned in the release notes) for 1.0.

Setting the DPI explicitly has not solved my problems. Win2000 1600x1200, 120dpi in system, neither 72 nor 96 dpi solves the problem.

Changing the DPI setting here to 96,72,100 or 120 (and restarting etc) makes no difference on my setup either- Windows 2000, Large Fonts 125%/120dpi, 1600x1200 resolution, 16bit color, and Matrox G200. BTW when scrolling various sites, and slashdot in particular, the single pixel shift sometimes also affects *images* that appear in the same table cell as the text.

Just checked on my Linux (Debian) box. The yahoo test case fails reliably on either 72 or 96 dpi (as set in Mozilla). 1024x768 screen.

This patch fixes the off-by-one pixel rendering errors when running on WinXP in 120 DPI for www.yahoo.com test case. It should also fix Linux.

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

Comment on attachment 83108 [details] [diff] [review] Align frames to pixel boundary. Updated patch sr=attinasi - but, could you add a comment about the pref being read only at initialization, and not updated dynamically. Also, that the default is TRUE and that it is temporary (I assume it is temporary...)

Comment on attachment 83108 [details] [diff] [review] Align frames to pixel boundary. Updated patch r=karnaze

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

Has this patch been applied? In 20020519 I still see the text off-by one on the horizontal glitch, but the at least "lines in images" bug (thought to be related?) seems to be gone. This is on WinME, 1024x768, large (125dpi) fonts, mozilla prefs set to 96dpi. I tried this with both "allow documents to use other fonts" on and off.

Comment on attachment 83430 [details] [diff] [review] Patch with comments suggested by attinasi This patch is incompatible with the trunk. When applied it hangs while opening the browser window

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

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

Attachment 83430 [details] [diff] seems to work on Mozilla 1.0RC3. This bug sometimes turns E's into F's, B's into E's and things like that, potentially causing confusion; in my experience it's far and away the most severe Mozilla bug at this point. As a Mozilla user, I wonder: Is it possible for this problem to be worked around (with attachment 83430 [details] [diff] [review] or a similar patch) for 1.0? Or is 1.0 going to ship with this bug?

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

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

Is the patch going to apply in the future? I applied Attachment 83430 [details] [diff] to Mozilla 1.0 and it seems to solve the problem I have been having for the last few months with various visual defects in rendering. I especially noticed it on Slashdot and Freshmeat. Now I don't see any problems with Slashdot or Freshmeat. This bug is in the offical release of Mozilla 1.1a.

This bug was introduced back on Jan 16, 2000 by the following checkin http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/layout/html/base/src&command=DIFF_FRAMESET&file=nsContainerFrame.cpp&rev2=1.81&rev1=1.80

This bug is result of an optimization which removed the PushState PopState in nsContainerFrame::Paint in favor of setting a negative translation to restore the state. Since the setting the negative translation is additive to the transformation matrix this results in the accumulation of small errors which normally do not make any difference. But when running 120DPI many frames are positioned precisely at twips locations which maps to a fractional 1/2 pixel scanline. During scrolling the number of negative offsets used to restore the state varies based on the container frame's children that intersect the damage rect. The small error between successive scrolls can result in a whole pixel shift if the textframe is positioned at 1/2 pixel boundary. Going back to the original PushState, PopState calls fixes the problem but re-introduces the performance problem that the negative translation optimization eliminated. The patch I attached fixes the problem by saving the translation components of the transformation matrix before painting the children and restores the translation components directly.

I tried attachment 87955 [details] [diff] [review] and found it does seem to fix the problem with two halves of a table's contents being one pixel misaligned, but doesn't address the problem of one pixel shift on selection of text. Attachment 83430 [details] [diff] seems to fix both problems.

I have these problems at 104dpi.

Comment on attachment 87955 [details] [diff] [review] Fix off by one error by changing how the rendering context state is saved/restored in nsContainerFrame's Paint method sr=waterson

Comment on attachment 87955 [details] [diff] [review] Fix off by one error by changing how the rendering context state is saved/restored in nsContainerFrame's Paint method r=dbaron

checked fix (attachment 87955 [details] [diff] [review]) into the trunk

Nice fix. Since MathML consists of little frames that are piled up, little cummulative errors can easily add up and become apparent. Should the fix be extended to nsViewManager::Refresh() which is another user of negative translation?

"Should the fix be extended to nsViewManager::Refresh() which is another user of negative translation?" That case should be OK. It always follows the same sequence of adding to the translation then subtracting translation. The problem I solved in this bug was where the sequence of positive and negative translations varied depending on the descendants of the container frame that intersected the damage rect. This caused the errors to accumulate differently between subsequent paints for the same container depending on the scroll position. I am resolving this bug as fixed, since the original problem: horizontal shifting of one line of pixels has been fixed by attachment 87955 [details] [diff] [review]. I created bug 152671 to cover the issue of one line of pixels being chopped off during scrolling when running in 120DPI.

With the 2002-06-19-08 trunk (Windows Me), I couldn't reproduce the problem as described. Tested under 120 dpi System setting. Marking Verified.

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch. pls check this in asap, then add the "fixed1.0.1" keyword.

checked fix (attachment 87955 [details] [diff] [review]) into the 1.0 branch

Verified on the branch Windows Me build (2002-07-16-05).

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

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

batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

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

Still present on Mozilla 1.2a. F.i. when viewing http://www.mozilla.org/projects/phoenix/phoenix-release-notes.html and scrolling up/down using the right scrollbar (not the keyboard). RH7.3 and Gnome with nVidia GeForce4 MX420, latest drivers.

I also see it with 101DPI on 2002091318 (trunk) running on Red Hat 7.3.94 ((null)) Public Beta under KDE.

I filed a new bug 171282 to cover the scrolling issue mentioned in comment 99 and comment 100. Please add any new off by one pixel scrolling issues to bug 171282. This bug has keywords and other notations which no longer apply, so I opened a new bug.

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

verified with new trunk nightly.