Closed Bug 70446 Opened 24 years ago Closed 24 years ago

Content renders on top of scrollbars (viewmanager3)

Categories

(Core :: Layout, defect)

Sun
Solaris
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: adam, Assigned: roc)

References

()

Details

Attachments

(2 files)

Enable the new 'scary' ViewManager on a recent build (tested on the 2001-02-27 nightly build). Visit the URL http://www.dark-legacy.net/silent-hill/index2.htm Resize the width of the browser (to about 760 pixels) so that the blinking 'PRESIDENT EVIL' animated GIF in the righthand column of links overlaps the scrollbar. This image will incorrectly draw *over* the scrollbars (and also cause redraw confusion within the scrollbar frames). This only occurs with ViewManager3 enabled, not ViewManager2.
Attached image Screenshot of undesirable effect. (deleted) —
I see this on linux build 2001-02-27-21 as well.
I also saw something like this on bugzilla with a dropdown select for the first time yesterday or today. It seems similar to the very old bug 5195, but occurring in more cases (perhaps due to some recent view manager change?).
Doh!
Blocks: 39621
Status: NEW → ASSIGNED
OK... The problem is my previous fix for bug 69146. It turns out that the result of nsIWidget::IsVisible can't be trusted. At least, for the ScrollFrame widget it returns "false" even though the widget is definitely visible. So the scrolled content doesn't get added to the opaque map when we paint the scroll container, and we paint the scrolled content again along with the container, which is really nasty in terms of performance. Furthermore for some unclear reason when painting the scroll container, images in the scrolled content aren't always clipped correctly. I presume this is a rendering bug (usually concealed because the scrolled content is normally drawn in its own widget and therefore clipped by the windowing system). Anyway, the fix is to ignore the widget visibility and look at the view visibility, which seems to be trustworthy. Also, instead of using the widget bounds and scaling them, it makes much more sense to use the view bounds. I will attach a patch to do this, but unfortunately I'm again in a situation where the patch supercedes a pending patch for a previous bug (bug 69346).
Depends on: 69346
This does what I said above ... basically, we ignore the widget data and use the view data instead. Works well in my build. Marc, Kevin?
patch looks good. r=kmcclusk@netscape.com
sr=attinasi
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verified fixed. Thanks!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: