From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.7) Gecko/20011221 BuildID: 2001122106 On many pages, vertical regions of the page will be shifted by one pixel to the left or right in relation to the rest of the page. This pertains to images as well as text. Reproducible: Sometimes Steps to Reproduce: 1. Open the URL in a new window wide enough but not tall enough to hold the whole image 2. Scroll to the end of the page 3. Scroll up again Actual Results: The part of the image that is redrawn is shifted one pixel to the right Expected Results: Consistent rendering This is a problem I have had since first using mozilla (0.95) and which has appeared thru all versions so far, under Windows 98 as well as Windows XP. Since it happens with many pages, I am surprised I couldn't find this bug listed yet. The only non-standard setting I have I believe could be of relevance is that I use large font sizes (120 dpi) in the advanced settings of the display properties.

WFM using 2002011503 Win2k.

Confirming issue in the Jan 22 build (2002-01-22-03) under Windows ME and OS X (2002-01-18-08).

Changing to compositor.

I resized the window so that only the horizontal scroll bar are active. Dragging scroll bar up and down causes painting issue on image.

confirming issue with MacOS 9.1 build 2002-01-16-14 I'm seeing this problem on *lots* of sites

The same behaviour has been reported in bug 80530 which is almost definitely a dup. Thus this bug could be related to bug 63336, bug 87738 or bug 97861.

MacOS 9.1 2002012308 issue no longer present -- seems to have been solved implicitly ???

I'm still seeing this on 20020125 Linux.

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

adding christine to this. we were getting reports of this through another channel indicating that link clicking (I've witnessed it on yahoo.com and news.com) and text selection can cause text pixel shifting, it's very wierd and can be subtle. seeing this on a 04/01/02 trunk build on win2k.

I can not reproduce the bug on WinXP with a current build. I have tried using 120DPI; 96DPIsettings and changing my screen resolution. I instrumented the view manager code that is reponsible for blitting the damaged area during painting and I noticed that the call to ScaleRoundOut on the damaged rect was returning values that were not as close to the nearest pixel as they should be after converting to twips. The patch corrects this. Help wanted: I need someone who is seeing the off by one pixel problems and has a current cvs build to apply my patch and see if it helps at all.

Jud: Can you apply my patch?

I've been seeing this at 96 DPI. I will try the patch as soon as I get into the office this morning.

I could only reproduce the pixel shift after changing my system dpi to 120. Links under on the Yahoo page are slightly after scrolling (and selection is present) . The problem for me is that it appeared only once so I need to find somes consistant steps to reproduce. Tested under Windows ME with the April 09th trunk build (2002-04-09-03).

Ken are you using Win2K, WinXP, Win98, WinME? What is your display resolution 800 X 600, 1024 X 768, etc? What is your display depth: 256 colors, 32768 color, true color etc? Under the windows display properties are you using small fonts or large fonts? Are you seeing the problem in MfcEmbed, Mozilla, Netscape trunk builds? If you are using Mozilla what setting do you have in the preferences under appearance-fonts-display resolution. Is it 96DPI, 76DPI or some other custom setting.

ok, let's see...I am using Win2k with a resolution of 1280x1024. display depth is true color (32bit). Font size is "small fonts, 96DPI". I see this in 0.9.9 and trunk (my latest pull is a couple days old now) in mfcembed and mozilla. mozilla font resolution is set at the default 96 DPI.

I can see the problem consistently on this page when loading as a local file!!

Also by loading this bug in mozilla and clicking through to the attachment! Click and hold on a link *or* select blocks of text and see it shift right 1 pixel....I have not changed from the settings listed above.

PATCH WORKS! Cool, verified and all that.

Sorry about the short post from yesterday. To clarify, I could reproduce the problem on my machine (specs in comment #16) 100% with the attached html content. I patched my copy of gkview and could no longer reproduce the problem after many attempts. Can we get this pushed to the trunk and 1.0 branch?

Note: I am seeking reviews/approval for attachment(id=78467). This patch fixes the problem Ken is seeing at 96DPI but does not fix the general problem seen at the 120DPI display setting. I can reproduce the problem on 120DPI, and the problem appears to be caused by a combination of pixel roundoff errors in the twips to pixel conversion produced as the result of inline frames not being positioned on pixel boundaries and specific layout combinations (centered table rows). On www.yahoo.com the line with: Personal: Addr Book · Briefcase · Calendar. etc is positioned at a location that corresponds to 11.5 pixel when running in 120DPI mode. This is the only line on that page which exhibits the off-by-one-pixel scrolling problem at 120DPI.

Comment on attachment 78467 [details] [diff] [review] Possible fix sr=attinasi

I tested with www.yahoo.com / win2000, 96dpi / mozilla set to 96 dpi Result without Kevin's patch: - Moving the edge of another app window over the links at the top causes the strange one pixel shifting Result with Kevin's patch: - The bad beahviour (shifting) is repaired

Comment on attachment 78467 [details] [diff] [review] Possible fix r=dcone

This bug covers only the 96DPI case. bug 80530 covers the 120DPI case. The underlying problems are different.

I just ran a few tests...confirmed that the 120DPI problem remains (display is set at 120DPI with mozilla at 96DPI). I also found that the attached sample does not exhibit the problem in 120DPI ... but I could see it at news.com

Comment on attachment 78467 [details] [diff] [review] Possible fix a=asa (on behalf of drivers) for checkin to the 1.0 branch

adt1.0.0+ per adt

Checked attachment 78467 [details] [diff] [review] into the Moz1.0.0 branch

Checked attachment 78467 [details] [diff] [review] into the trunk

Is bug 112673 a dupe of this?

If the problem in bug 112673 happens when the display is set to 96DPI it should be a dup of this. If the problem in bug 112673 happens when display is set to 120DPI then it is a dup of bug 80530. Reading through 112673 I didn't see any mention of a DPI setting so I would assume that bug is a dup of this one.

Based on Ken's comments regarding 96dpi issue, marking verified.

This is still NOT FIXED for me. I synced to cvs 1.0branch 15 minutes ago (20020413) and this does happen for me again on http://www.webfast.cz/, see: http://Xtrmntr.org/ORBman/tmp/webfast.cz-96dpi.png and I noticed this for the first time also in URLbar: http://Xtrmntr.org/ORBman/tmp/webfast.cz-urlbar.png http://Xtrmntr.org/ORBman/tmp/webfast.cz-urlbar2.png this is what I get if I move windows over URLbar. This does happen with Prefs/Appearance/Fonts/Display resolution: "System settings". This (both content scrolling/loading and URLbar shifting) doesn't happen when I change it to "96 dpi". My system is Athlon CPU, Matrox G450, Hyundai F910 19", 1280x1024/16bpp, xdpyinfo reports DPI 90x96, Mandrake 8.2 Linux, XFree84-4.2.0. -> Reopen?

>> This (both content scrolling/loading and URLbar shifting) doesn't >> happen when I change it to "96 dpi". Martin, For clarification, do you see any problems at 96DPI system setting? Are you changing the system font to 96DPI or mozilla?

When mozilla prefs set to 96DPI, I see no problems (for 1-2 weeks). When changed to "system settings" -> problem. X server reports 90x96 and I also have "default-resolutions = 90,96,100,100,75,75" line in /etc/X11/fs/config. I also tried "default-resolutions = 96,96,100,100,75,75" with mozilla set to "system settings" and the problem is still there. The only thing that makes this problem go away is to set mozilla prefs to "96 dpi".