Closed
Bug 70446
Opened 24 years ago
Closed 24 years ago
Content renders on top of scrollbars (viewmanager3)
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: adam, Assigned: roc)
References
()
Details
Attachments
(2 files)
(deleted),
image/gif
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
I see this on linux build 2001-02-27-21 as well.
Comment 3•24 years ago
|
||
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?).
Assignee | ||
Comment 5•24 years ago
|
||
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
Assignee | ||
Comment 6•24 years ago
|
||
Assignee | ||
Comment 7•24 years ago
|
||
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?
Comment 8•24 years ago
|
||
patch looks good.
r=kmcclusk@netscape.com
Comment 9•24 years ago
|
||
sr=attinasi
Assignee | ||
Comment 10•24 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•