199159 - chrome not repainting

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[(not reading, please use [e-mail] instead)]

chrome not repainting?

this is in my fresh win32, debug build.

I'll attach a screenshot

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: from mailnews

Comment 2

[(not reading, please use [e-mail] instead)]

Attachment: from browser

Comment 3

[(not reading, please use [e-mail] instead)]

twalker, do you see this?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I thought there were no smoketest blockers this morning...

Comment 5

[(not reading, please use [e-mail] instead)]

I just made this a blocker, since I see this problem all over the place.

could it be fall out from smooth scrolling?

Comment 6

[Tracy Walker [:tracy]]

I did not see anything like those screenshots with any of the builds this
morning; including windows.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I doubt it's smooth scrolling. It's most likely fallout from my checkin for bug
191474, which reorganized paint events to use a region instead of a rect for
platforms that support it (only GTK at present).

I've tested the rect-only path on GTK, though, and it works fine. So I don't
have a clue what's going on.

Better back me out again, I guess.

Comment 8

[(not reading, please use [e-mail] instead)]

hmm, I'm not seeing this on the official opt bits, only my debug bits.

I'll continue to look into it, and re-assign (or mark invalid) if necessary

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Could be something uninitialized. Can you try Purify or similar?

Comment 10

[WD]

I'm seeing painting problems throughout the entire browser starting with build
2003032508

Comment 11

[WD]

Attachment: Mozilla after other window dragged over top

I'm on Win2k, and if you drag another window over top of mozilla, it does not
repaint properly.

Comment 12

[(not reading, please use [e-mail] instead)]

data point, backing out #191474 fixes this.

so I'll look over that patch for something uninitialized.  

(I don't have purify here.)

Comment 13

[(not reading, please use [e-mail] instead)]

I got a temporary license for purify, and will try to purify later tonight.

Comment 14

[Darin Fisher]

this effects optimized builds as well on win2k.

Comment 15

[Suresh]

I see this too in my win2k debug build (pulled just now).

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

From the screenshots, it looks like everything is being painted at the right
position, but the wrong rect is being painted. It looks like maybe the rect
being painted is clipped a bit. Is the rect consistently too small by a small
amount, or is it sometimes totally wrong?

Comment 17

[(not reading, please use [e-mail] instead)]

I want to say that it's off by one pixel in both x & y directions.

mouse over a button, and it paints at 14,14 instead of 15,15, if that makes sense.

Comment 18

[(not reading, please use [e-mail] instead)]

maybe not.

but I also see paint problems in the browser window when I scroll.

I'll attach a screen shot.

back to roc, as backing out his fix for bug #191474 fixes this.

but I'll continue to investigate.

Comment 19

[(not reading, please use [e-mail] instead)]

I'm also seeing some assertions, but they might not be related.

NTDLL! 77f9180c()
nsDebug::Break(const char * 0x098dc080, int 729) line 288 + 25 bytes
nsDebug::Assertion(const char * 0x098dc0f4, const char * 0x098dc0b8, const char
* 0x098dc080, int 729) line 270 + 43 bytes
nsImageWin::DrawTile(nsImageWin * const 0x0b4caa78, nsIRenderingContext & {...},
void * 0x0b467c90, int 1, int 1, const nsRect & {...}) line 729 + 169 bytes
nsRenderingContextImpl::DrawTile(nsRenderingContextImpl * const 0x0a761560,
imgIContainer * 0x0b4c1ec0, int 14, int 14, const nsRect * 0x0013d774) line 905
+ 162 bytes
nsCSSRendering::PaintBackgroundWithSC(nsIPresContext * 0x044c4360,
nsIRenderingContext & {...}, nsIFrame * 0x0b0413c8, const nsRect & {...}, const
nsRect & {...}, const nsStyleBackground & {...}, const nsStyleBorder & {...},
const nsStylePadding & {...}, int 0) line 3354 + 145 bytes
nsCSSRendering::PaintBackground(nsIPresContext * 0x044c4360, nsIRenderingContext
& {...}, nsIFrame * 0x0b0413c8, const nsRect & {...}, const nsRect & {...},
const nsStyleBorder & {...}, const nsStylePadding & {...}, int 0) line 2821 +
155 bytes
nsFrame::PaintSelf(nsIPresContext * 0x044c4360, nsIRenderingContext & {...},
const nsRect & {...}, int 0, int 0) line 972 + 139 bytes
nsBoxFrame::Paint(nsBoxFrame * const 0x0b0413c8, nsIPresContext * 0x044c4360,
nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 1458 + 78 bytes
nsBoxFrame::PaintChild(nsIPresContext * 0x044c4360, nsIRenderingContext & {...},
const nsRect & {...}, nsIFrame * 0x0b0413c8, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 1542 + 127 bytes
nsBoxFrame::PaintChildren(nsIPresContext * 0x044c4360, nsIRenderingContext &
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay,
unsigned int 0) line 1675 + 145 bytes
nsBoxFrame::Paint(nsBoxFrame * const 0x0b0410ac, nsIPresContext * 0x044c4360,
nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 1485 + 120 bytes
nsBoxFrame::PaintChild(nsIPresContext * 0x044c4360, nsIRenderingContext & {...},
const nsRect & {...}, nsIFrame * 0x0b0410ac, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 1542 + 127 bytes
nsBoxFrame::PaintChildren(nsIPresContext * 0x044c4360, nsIRenderingContext &
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay,
unsigned int 0) line 1675 + 145 bytes
nsBoxFrame::Paint(nsBoxFrame * const 0x0b040fcc, nsIPresContext * 0x044c4360,
nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 1485 + 120 bytes
nsBoxFrame::PaintChild(nsIPresContext * 0x044c4360, nsIRenderingContext & {...},
const nsRect & {...}, nsIFrame * 0x0b040fcc, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 1542 + 127 bytes
nsBoxFrame::PaintChildren(nsIPresContext * 0x044c4360, nsIRenderingContext &
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay,
unsigned int 0) line 1675 + 145 bytes
nsBoxFrame::Paint(nsBoxFrame * const 0x0add4820, nsIPresContext * 0x044c4360,
nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 1485 + 120 bytes
nsBoxFrame::PaintChild(nsIPresContext * 0x044c4360, nsIRenderingContext & {...},
const nsRect & {...}, nsIFrame * 0x0add4820, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 1542 + 127 bytes
nsBoxFrame::PaintChildren(nsIPresContext * 0x044c4360, nsIRenderingContext &
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay,
unsigned int 0) line 1675 + 145 bytes
nsBoxFrame::Paint(nsBoxFrame * const 0x0add4654, nsIPresContext * 0x044c4360,
nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 1485 + 120 bytes
nsContainerFrame::PaintChild(nsIPresContext * 0x044c4360, nsIRenderingContext &
{...}, const nsRect & {...}, nsIFrame * 0x0add4654, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 279 + 129 bytes
nsContainerFrame::PaintChildren(nsIPresContext * 0x044c4360, nsIRenderingContext
& {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay,
unsigned int 0) line 199 + 138 bytes
nsContainerFrame::Paint(nsContainerFrame * const 0x0add4548, nsIPresContext *
0x044c4360, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 180 + 122 bytes
PresShell::Paint(PresShell * const 0x0a4df784, nsIView * 0x0a4f2a00,
nsIRenderingContext & {...}, const nsRect & {...}) line 5809 + 133 bytes
nsView::Paint(nsView * const 0x0a4f2a00, nsIRenderingContext & {...}, const
nsRect & {...}, unsigned int 0, int & -559038737) line 281 + 130 bytes
nsViewManager::RenderDisplayListElement(DisplayListElement2 * 0x0b3e9d08,
nsIRenderingContext & {...}) line 1247 + 121 bytes
nsViewManager::RenderViews(nsView * 0x0a4f2a00, nsIRenderingContext & {...},
const nsRegion & {...}, int & 0) line 1195 + 49 bytes
nsViewManager::Refresh(nsView * 0x0a4f2a00, nsIRenderingContext * 0x0a761560,
nsIRegion * 0x0a761648, unsigned int 1) line 789 + 98 bytes
nsViewManager::DispatchEvent(nsViewManager * const 0x0a4dee90, nsGUIEvent *
0x0013e650, nsEventStatus * 0x0013e564) line 1795 + 106 bytes
HandleEvent(nsGUIEvent * 0x0013e650) line 80 + 81 bytes
nsWindow::DispatchEvent(nsWindow * const 0x0a4f6c34, nsGUIEvent * 0x0013e650,
nsEventStatus & nsEventStatus_eIgnore) line 1150 + 38 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0013e650, nsEventStatus &
nsEventStatus_eIgnore) line 1175 + 92 bytes
nsWindow::OnPaint() line 5235 + 77 bytes
nsWindow::ProcessMessage(unsigned int 15, unsigned int 0, long 0, long *
0x0013eb04) line 3928 + 42 bytes
nsWindow::WindowProc(HWND__ * 0x0031028e, unsigned int 15, unsigned int 0, long
0) line 1437 + 100 bytes
$PUSER! 77e3a244()
$PUSER! 77e14730()
$PUSER! 77e1558a()
NTDLL! 77f91a7f()
nsWindow::DispatchStarvedPaints(HWND__ * 0x0031028e, long 0) line 3754 + 41 bytes
$PUSER! 77e1deaf()
$PUSER! 77e2e51d()
nsWindow::DispatchPendingEvents() line 3798 + 72 bytes
nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 5571525, long *
0x0013f0b0) line 4126 + 17 bytes
nsWindow::WindowProc(HWND__ * 0x0031028e, unsigned int 512, unsigned int 0, long
5571525) line 1437 + 100 bytes
$PUSER! 77e3a244()
$PUSER! 77e145e5()
$PUSER! 77e1a792()
nsAppShell::Run(nsAppShell * const 0x04ae3620) line 162 + 41 bytes
nsAppShellService::Run(nsAppShellService * const 0x04b4b518) line 479 + 85 bytes
main1(int 2, char * * 0x02451930, nsISupports * 0x044459d0) line 1271 + 94 bytes
main(int 2, char * * 0x02451930) line 1642 + 106 bytes
mainCRTStartup() line 338 + 59 bytes
PURERT! 3f004699()
PURERT! 3f47b025()

Comment 20

[parish]

Attachment: screenshot of pop-up problem

Is this the same problem?

This is what happens after using the context menu in the header pane when no
message is displayed. It may not show up with the intrinsic themes because they
don't, AFAIK, tile the message area with a GIF.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030324

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I have no access to Windows, and therefore no way to fix this bug (unless
someone can reproduce it on Linux, but AFAIK no-one has yet).

Comment 22

[David G King]

My nightly build (2003032504-TRUNK WinXP) doesn't show these symptoms. Also, it
looks like the checkin for Bug #191474 went in before my build, so maybe it's
something else?

Sorry, I don't have a debug build to test with....

Comment 23

[WD]

Attachment: Additional Screenshot

Doesn't seem to be off by a fixed amount, or by one pixel...

Comment 24

[Jim Dunn]

I think I am seeing this... with this morning's clean debug build on win2k
I am getting this assert all over the place, especially with chat, anytime
someone types something in, the assert "Offset(s) are bigger than image...
nsImageWin::DrawTile line 729" pops up.

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

bug 194791 is filed about said assertion

Comment 26

[(not reading, please use [e-mail] instead)]

working with roc on irc...

Comment 27

[(not reading, please use [e-mail] instead)]

also try this:

http://surfmind.com/musings/index.cfm?cat=mozilla

mouse over the links.  they are off by 1x1

screen shot coming...

Comment 28

[(not reading, please use [e-mail] instead)]

Attachment: screen shot of moused over links in http://surfmind.com/musings/index.cfm?cat=mozilla

Comment 29

[(not reading, please use [e-mail] instead)]

Attachment: a fix, from roc

Comment 30

[(not reading, please use [e-mail] instead)]

fixed.  thanks roc.

Comment 31

[Matthias Versen [:Matti]]

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

Comment 32

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

It's worth noting that some gfx ports (GTK, at least, and I think some others)
enforce p2t being an integer, but some don't.

Comment 33

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

I think we should patch the other GFX ports like was done to GTK in bug 16200
comment 10, so that this patch won't make things worse for, say, Windows users
who set an unusual (or correct!) logical resolution in their advanced settings.

Comment 34

[Kai Engert (:KaiE:)]

After this checkin, the only recent checkin, we now see a compiler error on a
linux tinderbox:

c++ -o nsXBLDocumentInfo.o -c -DOSTYPE=\"Linux2.4\" -DOSARCH=\"Linux\"
-I/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/mozilla/content/xbl/src/../../base/src
-I/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/mozilla/content/xbl/src/../../html/style/src
-I/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/mozilla/content/xbl/src/../../html/base/src
-I/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/mozilla/content/xbl/src/../../html/document/src
-I/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/mozilla/content/xbl/src/../../xml/document/src
-I/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/mozilla/content/xbl/src/../../xul/content/src
 -I../../../dist/include/xpcom -I../../../dist/include/string
-I../../../dist/include/js -I../../../dist/include/dom
-I../../../dist/include/gfx -I../../../dist/include/layout
-I../../../dist/include/xultmpl -I../../../dist/include/widget
-I../../../dist/include/view -I../../../dist/include/caps
-I../../../dist/include/htmlparser -I../../../dist/include/necko -I../../../dist/i!
nclude/xpco
nnect -I../../../dist/include/pref -I../../../dist/include/docshell
-I../../../dist/include/webshell -I../../../dist/include/chrome
-I../../../dist/include/lwbrk -I../../../dist/include/xul
-I../../../dist/include/xuldoc -I../../../dist/include/rdf
-I../../../dist/include/imglib2 -I../../../dist/include/unicharutil
-I../../../dist/include/locale -I../../../dist/include/content
-I../../../dist/include
-I/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/tinderbox-obj/dist/include/nspr   
  -I/usr/X11R6/include   -fPIC  -I/usr/X11R6/include -fno-rtti -fno-exceptions
-Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -pedantic -Wno-long-long -Wabi -fmessage-length=0
-fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -O  -I/usr/X11R6/include
-DMOZILLA_CLIENT -include ../../../mozilla-config.h
-Wp,-MD,.deps/nsXBLDocumentInfo.pp
/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/mozilla/content/xbl/src/nsXBLDocumentInfo.cpp
In file included from ../../../dist/include/content/nsIXBLDocumentInfo.h:49,
                 from
/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/mozilla/content/xbl/src/nsXBLDocumentInfo.h:38,
                 from
/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/mozilla/content/xbl/src/nsXBLDocumentInfo.cpp:39:
../../../dist/include/string/nsString.h: In destructor `virtual
nsCAutoString::~nsCAutoString()':
../../../dist/include/string/nsString.h:399: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
NEXT ERROR make[5]: *** [nsXBLDocumentInfo.o] Error 1
make[5]: *** Waiting for unfinished jobs....
/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/mozilla/content/xbl/src/nsXBLResourceLoader.cpp:
In member function `void nsXBLResourceLoader::LoadResources(PRBool*)':
/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/mozilla/content/xbl/src/nsXBLResourceLoader.cpp:149:
warning: unused variable `nsresult rv'
make[5]: Leaving directory
`/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/tinderbox-obj/content/xbl/src'
make[4]: *** [libs] Error 2
make[4]: Leaving directory
`/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/tinderbox-obj/content/xbl'
make[3]: *** [libs] Error 2
make[3]: Leaving directory
`/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/tinderbox-obj/content'
make[2]: *** [tier_9] Error 2
make[2]: Leaving directory
`/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/tinderbox-obj'
make[1]: *** [default] Error 2
make[1]: Leaving directory
`/mnt/4/tinderbox/brad/Linux_2.4.19_Clobber/tinderbox-obj'
make: *** [build] Error 2

Comment 35

[(not reading, please use [e-mail] instead)]

that bustage isn't from my checkin, is it?

I checked into mozilla/view, not string or xbl

Comment 36

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> I think we should patch the other GFX ports

We definitely should.

But I don't know if there are a lot of people using Mozilla with such DPI
settings , since lots of things can go wrong when p2t is not an integer.

Comment 37

[Benjamin Smedberg]

I set my DPI on windows to the actual screen measurements, as do many graphic
designers who use PageMaker or Quark. And it's definitely non-integral.

Comment 38

[parish]

Attachment: screenshot

Seth: I'm confused. This is what I see at surfmind.com

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030324

Why do the links appear different on my system than they do on yours?

Comment 39

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Benjamin: if you see problems like this in the latest builds, please let us know.

We can fudge the Mozilla internal DPI to make problems like this go away without
forcing you to change your DPI settings.

Comment 40

[(not reading, please use [e-mail] instead)]

> Seth: I'm confused. This is what I see at surfmind.com

parish, not everyone saw this bug.

Comment 41

[Stefan Borggraefe]

I still see this bug with Build 2003032704 and Windows 2000 SP3 when I move
other application´s windows over a Mozilla window. The DPI value is set to 127.

I´ll attach a screenshot in a minute...

Comment 42

[Stefan Borggraefe]

Attachment: Repainting problems with Build 2003032704

Comment 43

[George K.]

I am still seeing this issue with build 2003032708 on Win2K SP3.

As this issue still occurs for more than one user in builds from after the
03/26/2003 11:02 patch checkin, I suspect that the issue persists.

My DPI is set at 96, a nice, round, integer.

Comment 44

[Sam Hulick]

This is not fixed.  I saw it with build 2003032608 on WinXP Pro SP1 last night.
 Opened a window, dragged it around in front of Mozilla, and it left trails.

Comment 45

[Eugene Savitsky]

moz 2003032708, Win XP.

Open the Windows Task Manager. Move it around a Mozilla window with mouse the
mozilla windows becomes totally unviewable since it will contain the half of the
the Windows Task Manager artefacts.

Comment 46

[Jason Bassford]

I'm still seeing it too (2003032704 / XP) - moving a window around on top of
Mozilla causes ghosting / artifacts all over the place.

Reopening.

Comment 47

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Are any of you who still see the problem able to build Mozilla and try a patch
for me?

Comment 48

[parish]

Yes I'm seeing this too now, 2003032721, XP-Pro SP1

I can build Mozilla so I can test your patch.

Comment 49

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: test patch

parish, can you test this to see if it fixes your problems?

As far as I can tell, this should restore exactly the rounding behavior that we
had before my patch landed.

Comment 50

[parish]

Build is now spinning.

Comment 51

[parish]

roc: it's an improvement, but it's still not right although the corruption is
less than it was.

Comment 52

[Robert O'Callahan (:roc) (email my personal email if necessary)]

screenshot?

Comment 53

[parish]

Actually, I don't think it is any better. When I posted comment 51 I'd been
testing it with an empty browser window (about:blank) and that leaves very few
artifacts, but with a webpage loaded it is just as bad. Sorry for the
misinformation :-[

If you want any other patches testing, just ask.

Comment 54

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I just ran Win32 Mozilla in WINE and it seemed to work fine. I'm at a loss.

Comment 55

[Brian Ryner (not reading)]

Attachment: patch

How about this one?

Comment 56

[Brian Ryner (not reading)]

Comment on attachment 118869 [details] [diff] [review]
patch

This fixes the painting problems for me on win32.

Comment 57

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 118869 [details] [diff] [review]
patch

Urk!

Thanks heaps!

Comment 58

[Asa Dotzler [:asa]]

Comment on attachment 118869 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.4a.

Comment 59

[Brian Ryner (not reading)]

checked in.

Comment 60

[Sam Hulick]

Attachment: Not yet fixed..

Still broken, it appears, for build 2003032908 on XP Pro SP1

Comment 61

[parish]

Your build pre-dates the checkin by ~7 hours.

Comment 62

[George K.]

Sorry for the spam, but I can verify as FIXED in 2003033108.  Try as I might
Mozilla just keeps repaining that chrome... ;-)

Comment 63

[Thomas Becker]

I still experience this bug with 2003033108, win2k, and 134 dpi set in the
advanced display properties.

Comment 64

[Stefan Borggraefe]

WFM with build 2003033009 and Windows XP SP1.

Comment 65

[David G King]

WFM as well.

I think the dpi issue should be addressed in a different bug as it would appear
to be an interesting problem which may not actually be a Mozilla bug. Just look
at the nVidia problem that was a buggy driver issue as an example.

Comment 66

[Thomas Becker]

Well, it worked before (e.g. 20030327), only minor glitches when scrolling. Now
it's nearly unusable, I assume there's still some kind of miscalculation. I can
confirm that it works with the standard 96 dpi.

Comment 67

[Robert O'Callahan (:roc) (email my personal email if necessary)]

People who STILL sees problems:
-- please try the patch in attachment 118792 [details] [diff] [review], if you can
-- Attach a screenshot, as far as I can tell we don't have any screenshots here
from post-bryner-checkin builds
-- try setting DPI to 96 and report if that fixes things

Comment 68

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

Comment on attachment 118792 [details] [diff] [review]
test patch

Wouldn't landing this patch be likely to fix the problems at unusual DPIs?

Comment 69

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I hope so, since it restores the rounding behavior that we used to have. But I'd
like some people to try it out to be sure.

Comment 70

[MightyMu]

I am still seeing chrome problems, but I am unable to determine if they're the
same as others reported in this bug. The problems start for me with builds from
March 26th. (2003-03-25-04 is the last build without this problem). It persists
through 1.4a, as well as today's most recent nightly.
I am running Windows 2k Pro, P2-450Mhz, 384Mb RAM, ATI All-in-Wonder 128 (Rage
128) with latest ATI drivers, display set to 96dpi.
This problem renders mozilla near-unusable.
I will attach a screenshot.

Comment 71

[MightyMu]

Attachment: chrome errors in 1.4a

Screenshot is of mozilla-win32-1.4a-talkback, running on Win2k with a clean
profile

Comment 72

[Doug Halamay]

I'm having the exact same problems in 1.4a.  It appears to have started around
the 26th of March.  I'm using WinXP with a Geforce 2 Ultra, with the latest drivers.

It seems that all of the scrollbars and status bar along the right and bottom
sides of the window are simply missing...and then chrome is not repainting
within the browser window itself.  It does this on a clean install with a new
profile, with either classic or modern themes.

I think this bug needs to be reopened...it renders Mozilla/Phoenix completely
unusable.  I've had to revert back to a March 24th build of Mozilla and Phoenix.

Comment 73

[Thomas Becker]

Attachment: after applying patch from attachment 118792

better than before but still drawing errors in chrome and 1 pixel errors due to
scrolling and context menues

Comment 74

[Thomas Becker]

Attachment: after applying patch from attachment 118792

win2k, 134 dpi, applied patch from attachment 118792 [details] [diff] [review] to 20030402 from cvs

much better than before but still drawing errors in chrome and 1 pixel errors
due to scrolling and context menues

Comment 75

[Thomas Becker]

oops, sorry for the duplicated entries

I should have mentioned that I get a lot of

###!!! ASSERTION: Offset(s) are bigger than image.  Caller to DrawTile needs to
do more thinking!: 'aSXOffset < mBHead->biWidth && aSYOffset < mBHead->biHeight'
, file c:/mozilla/mozilla/gfx/src/windows/nsImageWin.cpp, line 729

Comment 76

[MightyMu]

Aha. I was able to make the problem go away by changing my *windows* display
setting to 96dpi (the 96dpi setting to which I had referred in my previous post
was Mozilla's 'Preferences > Appearance > Fonts' setting). It had been set at
106dpi previously, and up until the 25th or so, Mozilla worked fine.

Comment 77

[Doug Halamay]

Re: comment 76, I can also verify that changing the dpi setting in my Windows
display applet to 96 dpi (from 100 dpi) fixes the problem.  But this is not an
acceptable workaround, since I need the rest of Windows to be at 100 dpi.

Someone still needs to look into this...and this bug should be reopened.

Comment 78

[David G King]

I was playing with the Mozilla dpi setting, and while I couldn't duplicate the
problem, I did get this JS error whenever I changed the dpi setting.

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIMenuBoxObject.activeChild]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: <unknown filename> ::
onxblpopupshowing :: line 7"  data: no]

Comment 79

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Thomas Becker, can you try changing the Windows DPI setting to 96dpi? I'm not
asking you to change that permanently. I just want to know how it's affecting
this bug on your machine.

If it turns out to be the DPI setting then I think we need to add some code to
Windows GFX to make p2t be an integer.

Comment 80

[Thomas Becker]

Windows advanced display properties 96dpi works fine (with or without the
patch).  Windows advanced display properties 134dpi gives drawing errors as
described earlier.

I thought I already said that in comments #63 and #66, sorry for the
misunderstanding. I don't know what Mozilla dpi settings are good for, btw.

Comment 81

[Thomas Becker]

It works also nice with "big fonts" set in the advanced display properties of
windows (win2k), corresponding to 120 dpi.

Comment 82

[David G King]

When I was playing with the Mozilla dpi setting (and restaring Mozilla just in
case) I got no perceivable differance in display attributes. So, besides the JS
error, it doesn't really appear to do much at all. Or maybe that's just because
of the JS error?

Comment 83

[Scott Thorne]

I also think it should be reopened.  Comments 72-74 and 77 echo much of the same
things I would write.  The image attached in them looks much like mine.  I also
don't think I should have to go change dpi settings in Windows or in the browser
to work around this.

I experience it on Moz 1.4a and a recent Pheonix nightly (within ppast 2 or 3
days) on W2k.  Also on WinXP with 1.4a and the same Peonix build.

Doesn't happen with earlier Pheonix builds of Moz 1.3b or 1.3 on eaither OS.  In
fact, I'm using Moz 1.3b now so I can use a browser.

Maybe a newer build has fixed this?  I guess I'll try one

Comment 84

[Scott Thorne]

Attachment: screenshot of 1.4a painting wrong

This PNG image shows how this bug is affecting me, in this case, Moz 1.4a on
WinXP

Comment 85

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: try this

OK, whoever is using nonstandard DPI and can build Mozilla on Windows, please
try this patch. Completely untested, untouched by any compiler! :-)

Comment 86

[David G King]

OK, due to all the comments, and the new (alpha) patch from roc, Reopening.

Oh, and a bit of trivia, I don't think 96dpi is a standard so much as it's the
default setting.

Comment 87

[parish]

I'm currently spinning a new build to test roc's patch. It should be done in
about half an hour

Comment 88

[parish]

That fixes it roc :-D

I have built the SEA installer so others can try it and am currently uploading
it to ftp://users.freebsd.org.uk/pub/mark but I'm only on dial up so it will
take ~1 hour. The file size is 14,316KB and the MD5 is
1200a2e256531e6f37af19ae38c49692 

Note that the Build ID shows as 2003040512 but it is actually 2003040216 with
this patch added.

Since the behaviour seems a bit ad hoc (I had to go to 134dpi to recreate it but
comment 77 reports it at 100dpi) I suspect other things, such as resolution and
possibly video drivers, come into the equation. I am running WinXP-SP1, ATI
Radeon 7000 with the Catalyst 3.2 drivers at 1280x1024x32.

As well as the artefacts left by dragging other windows over Moz I also saw the
following:

Throbber corrupted

Scrollbars not drawn in the browser (just a white area where it shoukd be)
although you can scroll with them even though you can't see them.

Scrollbars drawn, but corrupted, in Mail/News and when the slider is dragged the
contents scroll but the slider doesn't move.

Any attempt to scroll with smoothScroll enabled would crach Mozilla in gklayout.dll

This patch fixes all of the above.

Comment 89

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 119533 [details] [diff] [review]
try this

this patch makes mPixelsToTwips be an integer on Windows. Fixes paint
corruption issues and is generally a good idea.

Comment 90

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Thanks parish! Can you check printing and print preview to make sure they still
look OK?

Comment 91

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

Comment on attachment 119533 [details] [diff] [review]
try this

r+sr=dbaron, although I slightly prefer construction-style casts.

Comment 92

[parish]

Re comment 90. Yes, Print Preview and Printing appear to be fine

Comment 93

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fix checked in. I hope this does it!!

Comment 94

[Doug Halamay]

I can verify that this fixes the problem for me...all repainting errors are
gone, and everything is back to normal.  I'm running 100dpi in Windows advanced
display, with WinXP-SP1, at 1600x1200 with a Geforce 2 Ultra with the latest
drivers.

Good work!  Now I just have to wait for a new Phoenix nightly, and all will be good.

Comment 95

[Scott Thorne]

Moz 20030406 nightly WFM.  Haven't check Phoenix yet, but trust this Moz fix
will propogate to Phoenix in due time.  THANKS for the work on this item.

Comment 96

[Doug Halamay]

WFM in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030407
Phoenix/0.5+

And it's been working since the 20030406 build.  Good job again!

Comment 97

[punkadiddle]

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

Comment 98

[Malcolm Rowe]

Comment on attachment 119533 [details] [diff] [review]
try this

This patch is the cause of bug 211092.