[Webkit-unassigned] [Bug 5909] (Gmail) Absolutely positioned element over iframe incorrectly scrolls along with iframe, and leaves trail when scrolling

bugzilla-daemon at opendarwin.org bugzilla-daemon at opendarwin.org
Sun Jan 22 20:30:22 PST 2006


darin at apple.com changed:

           What    |Removed                     |Added
                 CC|                            |darin at apple.com,
                   |                            |hyatt at apple.com

------- Comment #6 from darin at apple.com  2006-01-22 20:30 -------
This is easy to fix. It's caused by the setting of copiesOnScroll, which is set
by calling QScrollView::setStaticBackground. I believe that the sense of the
setStaticBackground boolean is backwards, by the way, because when it's true we
do the slow scrolling and when it's false we do the fast scrolling. But the
calling code in FrameView also looks backwards so it cancels out -- the
useSlowRepaints field has a logical name.

Anyway, FrameView::clear and FrameView::layout both call setStaticBackground
and ask for fast scrolling in some cases. But they can't do that if this frame
overlaps any other element in front of it.

Since there's no fast way to find out if a frame has anything in front of it,
we're in a bit of a quandry. We can change all the callers to never set the
fast scrolling mode for a view for a subframe, but that will make scrolling
slower for frames on frameset pages.

I think that's probably the best fix.

It's as simple as changing this:


to this:

    setStaticBackground(d->useSlowRepaints && !m_frame->parentFrame());

Although I also think we should reverse the sense of setStaticBackground, and
possible change its name to setUseSlowRepaints for clarity.

Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list