Closed Bug 106355 Opened 23 years ago Closed 23 years ago

Loading any page paints top of page over the UI

Categories

(Core Graveyard :: GFX, defect)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: roc)

References

Details

Attachments

(1 file, 1 obsolete file)

D'oh --- here's the patch with the warning printf
1.66 KB, patch
kmcclusk
: review+
waterson
: superreview+
Details | Diff | Splinter Review 
Build 2001-10-23-08.  Start the browser (mozilla about:blank).  Load a page.  I
chose www.mozilla.org.  Notice that the menus and navigation buttons on the
toolbar disappear and are replaced with the mozilla graphic.  Making those areas
repaint by moving the mouse over them or minimizing and unminimizing the window
fixes the problem until the next page load....
This was not a problem at 2001-10-22-13 (pulled from cvs from that date/time)
I see similar painting problems looking at the tinderbox page and scrolling up
and down by dragging the thumb, and while reading mail, where parts of the
window just don't redraw properly. Build 2001102308 on Linux.
Ok.  This was caused by roc+moz's checkin of 10/22/2001 18:35 (the Refresh()
rewrite).

Reassinging to roc+moz
Assignee: kmcclusk → roc+moz
is this the same as bug 106309?
Blocks: 106309
Sounds like my bug but I can't reproduce it with a build I pulled and built
yesterday morning. I'm on Linux. Tried all the methods mentioned here, in
Classic and Modern themes just in case. I will try the latest Linux nightly.
I'm using 2001102308 right now and I can't reproduce any of these problems. How
can we proceed? Should I back out the change?
I'm using CVS HEAD and I've had the problem
for about two days.  IMO it's worth a backout
for now, and we will a) see whether this was
really the cause, and b) fix it at leisure.

Hmm. From nsRenderingContextGTK::CopyOffScreenBits()

> #if 0
>   // XXX impliment me
>   if (aCopyFlags & NS_COPYBITS_USE_SOURCE_CLIP_REGION)
>   {
>     // we should use the source clip region if this flag is used...
>     nsIRegion *region;
>     CopyClipRegion();
>   }
> #endif

Windows and Mac seem to support USE_SOURCE_CLIP_REGION. Can anyone reproduce
this bug there? So far all the reports I see are Linux. (Doesn't explain why I
can't see it on my Linux box though.)

Adding Blizzard, for wisdom on why this might be GTKFE-only.

Now I can't see how this EVER worked given that USE_SOURCE_CLIP_REGION doesn't
do anything with GTK.
Hmm, do I need reviews for backout?

I have to go to work and a bunch of meetings. Someone else will have to do the
backout, it's OK with me. Here are the commands:
cvs update -j3.76 -j3.75 mozilla/view/src/nsViewManager.h
cvs update -j3.203 -j3.202 mozilla/view/src/nsViewManager.cpp
*** Bug 106309 has been marked as a duplicate of this bug. ***
Thanks to bzbarsky I found the bug.  On some Linux boxes (not all), we are
receiving paint requests for areas completely outside the widget's view area.
This triggered a bug in my changed code. I will attach a patch which bz confirms
fixes the bug for him. It includes a debug message for this case because we
might still want to track down why these bogus repaints are being generated.

I'd like r and sr please.
By the way, the reason USE_SOURCE_CLIP_REGION works in GTK, as far as I can tell
from looking at the code, is that in GTK the clip region is shared across all
drawing surfaces for the rendering context, so USE_SOURCE_CLIP_REGION is
meaningless there.
Well, that certainly seems to fix it.

Comment on attachment 54917 [details] [diff] [review]
Don't copy offscreen buffer unless we set the clip region and painted something

r=kmcclusk@netscape.com
Attachment #54917 - Flags: review+
Attachment #54917 - Attachment is obsolete: true
Sorry, forgot to include the warning printf. Please apply r and sr to the new
patch. Thanks!
Comment on attachment 54927 [details] [diff] [review]
D'oh --- here's the patch with the warning printf

r=kmcclusk@netscape.com
Attachment #54927 - Flags: review+
Blocks: 106239
Blocks: 106498
*** Bug 106557 has been marked as a duplicate of this bug. ***
Wouldn't it be cleaner to use NS_WARNING which adds file and line number to the
warning?
Yeah, except that NS_WARNING can't print parameters.
Doh, missed that. Guess you could build the string on the fly before passing it
to NS_WARNING, but nevermind :-)
This problem also occurs in the Mail component.
Comment on attachment 54927 [details] [diff] [review]
D'oh --- here's the patch with the warning printf

nifty; sr=waterson
Attachment #54927 - Flags: superreview+
Fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
No longer blocks: 106239
*** Bug 106239 has been marked as a duplicate of this bug. ***
*** Bug 106632 has been marked as a duplicate of this bug. ***
*** Bug 106673 has been marked as a duplicate of this bug. ***
No longer blocks: 106498
*** Bug 106498 has been marked as a duplicate of this bug. ***
*** Bug 106742 has been marked as a duplicate of this bug. ***
*** Bug 108447 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: