Closed Bug 199159 Opened 21 years ago Closed 21 years ago

chrome not repainting

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: sspitzer, Assigned: roc)

References

Details

(Keywords: regression, smoketest)

Attachments

(16 files, 1 obsolete file)

from mailnews
42.50 KB, image/gif
Details
from browser
26.18 KB, image/gif
Details
Mozilla after other window dragged over top
15.73 KB, image/gif
Details
screenshot of pop-up problem
17.83 KB, image/png
Details
Additional Screenshot
5.55 KB, image/gif
Details
screen shot of moused over links in http://surfmind.com/musings/index.cfm?cat=mozilla
48.46 KB, image/gif
Details
screenshot
14.50 KB, image/png
Details
Repainting problems with Build 2003032704
40.00 KB, image/png
Details
test patch
1.14 KB, patch
Details | Diff | Splinter Review
patch
626 bytes, patch
roc
: review+
roc
: superreview+
asa
: approval1.4a+
Details | Diff | Splinter Review
Not yet fixed..
63.58 KB, image/gif
Details
chrome errors in 1.4a
59.98 KB, image/png
Details
after applying patch from attachment 118792
102.08 KB, image/jpeg
Details
after applying patch from attachment 118792
102.08 KB, image/jpeg
Details
screenshot of 1.4a painting wrong
60.98 KB, image/png
Details
try this
1.08 KB, patch
dbaron
: review+
dbaron
: superreview+
Details | Diff | Splinter Review 
chrome not repainting?

this is in my fresh win32, debug build.

I'll attach a screenshot
Severity: normal → critical
twalker, do you see this?
Severity: critical → blocker
Keywords: smoketest
Summary: chrome not repainting? → chrome not repainting
I thought there were no smoketest blockers this morning...
I just made this a blocker, since I see this problem all over the place.

could it be fall out from smooth scrolling?
I did not see anything like those screenshots with any of the builds this
morning; including windows.
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.
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
Assignee: roc+moz → sspitzer
Could be something uninitialized. Can you try Purify or similar?
I'm seeing painting problems throughout the entire browser starting with build
2003032508
I'm on Win2k, and if you drag another window over top of mozilla, it does not
repaint properly.
data point, backing out #191474 fixes this.

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

(I don't have purify here.)
Status: NEW → ASSIGNED
Depends on: 191474
I got a temporary license for purify, and will try to purify later tonight.
this effects optimized builds as well on win2k.
I see this too in my win2k debug build (pulled just now).
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?
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.
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.
Assignee: sspitzer → roc+moz
Status: ASSIGNED → NEW
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()

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
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).
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....
Attached image Additional Screenshot — 
Doesn't seem to be off by a fixed amount, or by one pixel...
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.

working with roc on irc...
also try this:

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

mouse over the links.  they are off by 1x1

screen shot coming...
Attachment #118554 - Attachment is patch: false
Attachment #118554 - Attachment mime type: text/plain → image/gif
fixed.  thanks roc.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 199315 has been marked as a duplicate of this bug. ***
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.
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.
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


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

I checked into mozilla/view, not string or xbl
> 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.
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.
Attached image 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?
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.
> Seth: I'm confused. This is what I see at surfmind.com

parish, not everyone saw this bug.
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...
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.
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.
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.
I'm still seeing it too (2003032704 / XP) - moving a window around on top of
Mozilla causes ghosting / artifacts all over the place.

Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Are any of you who still see the problem able to build Mozilla and try a patch
for me?
Flags: blocking1.4a+
Yes I'm seeing this too now, 2003032721, XP-Pro SP1

I can build Mozilla so I can test your patch.
Attached patch test patch — — Splinter Review 
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.
Attachment #118558 - Attachment is obsolete: true
Build is now spinning.

roc: it's an improvement, but it's still not right although the corruption is
less than it was.
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.



I just ran Win32 Mozilla in WINE and it seemed to work fine. I'm at a loss.
Attached patch patch — — Splinter Review 
How about this one?
Comment on attachment 118869 [details] [diff] [review]
patch

This fixes the painting problems for me on win32.
Attachment #118869 - Flags: review?(roc+moz)
Comment on attachment 118869 [details] [diff] [review]
patch

Urk!

Thanks heaps!
Attachment #118869 - Flags: superreview+
Attachment #118869 - Flags: review?(roc+moz)
Attachment #118869 - Flags: review+
Attachment #118869 - Flags: approval1.4a?
Comment on attachment 118869 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.4a.
Attachment #118869 - Flags: approval1.4a? → approval1.4a+
checked in.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Attached image Not yet fixed.. — 
Still broken, it appears, for build 2003032908 on XP Pro SP1
Your build pre-dates the checkin by ~7 hours.

Sorry for the spam, but I can verify as FIXED in 2003033108.  Try as I might
Mozilla just keeps repaining that chrome... ;-)
I still experience this bug with 2003033108, win2k, and 134 dpi set in the
advanced display properties.
WFM with build 2003033009 and Windows XP SP1.
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.
Status: RESOLVED → VERIFIED
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.
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 on attachment 118792 [details] [diff] [review]
test patch

Wouldn't landing this patch be likely to fix the problems at unusual DPIs?
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.
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.
Attached image chrome errors in 1.4a — 
Screenshot is of mozilla-win32-1.4a-talkback, running on Win2k with a clean
profile
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.
better than before but still drawing errors in chrome and 1 pixel errors due to
scrolling and context menues
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
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
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.

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.
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]
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.
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.

It works also nice with "big fonts" set in the advanced display properties of
windows (win2k), corresponding to 120 dpi.
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?
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
This PNG image shows how this bug is affecting me, in this case, Moz 1.4a on
WinXP
Attached patch try this — — Splinter Review 
OK, whoever is using nonstandard DPI and can build Mozilla on Windows, please
try this patch. Completely untested, untouched by any compiler! :-)
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I'm currently spinning a new build to test roc's patch. It should be done in
about half an hour

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 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.
Attachment #119533 - Flags: superreview?(dbaron)
Attachment #119533 - Flags: review?(dbaron)
Thanks parish! Can you check printing and print preview to make sure they still
look OK?
Comment on attachment 119533 [details] [diff] [review]
try this

r+sr=dbaron, although I slightly prefer construction-style casts.
Attachment #119533 - Flags: superreview?(dbaron)
Attachment #119533 - Flags: superreview+
Attachment #119533 - Flags: review?(dbaron)
Attachment #119533 - Flags: review+
Re comment 90. Yes, Print Preview and Printing appear to be fine

Fix checked in. I hope this does it!!
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
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.
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.
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!
*** Bug 200301 has been marked as a duplicate of this bug. ***
Comment on attachment 119533 [details] [diff] [review]
try this

This patch is the cause of bug 211092.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: