[chromium] Force slow scrolling path for non-composited frames in a composited page
Created attachment 101666 [details] Patch
*** Bug 64915 has been marked as a duplicate of this bug. ***
Comment on attachment 101666 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=101666&action=review Unofficially, the code looks good to me. We could also cut the explanation out and just say we don't handle it. > Source/WebCore/ChangeLog:10 > + The chromium compositor does not properly handle fast path scrolls for non-composited iframe in a composited > + page. In particular, we don't receive invalidations that are outside the viewport bounds for non-composited > + iframes, but we still try to use the contents from tiles that extend outside the viewport when they are scrolled > + in to view. For the main frame we do receive invalidations outside the viewport (see > + FrameView::clipsRepaints()) so everything works out. I thought the larger issue was that we don't handle the different scroll offsets from the main frame and the sub frame. This causes a problem because we're scrolling via redrawing the root directly at the scroll offset rather than scrolling via copying a rectangle from the backbuffer based on the offset that gets passed to WebViewImpl::scrollRootLayerRect.
Created attachment 101670 [details] more accurate changelog
Committed r91591: <http://trac.webkit.org/changeset/91591>