-
simon.fraser@apple.com authored
Roll r96070 back in now that the crash has been fixed in r96130. Source/WebCore: Reviewed by Darin Adler. When non-overlay scrollbars are hidden on a composited iframe, nothing invalidated the scrollbar areas or the scroll corner, so the scrollbars appear to remain. Fix by invalidating the scrollbars and scroll corner when they are removed. Invalidation on scrollbar creation appears to happen via updating the scrollbar style. Tested by compositing/iframes/repaint-after-losing-scrollbars.html which no longer shows stale scrollbars when run manually, even though the green squares are missing from the pixel result (bug 67878). * page/FrameView.cpp: (WebCore::FrameView::updateScrollCorner): Pass the corner rect into invalidateScrollCorner(). * platform/ScrollView.cpp: (WebCore::ScrollView::setHasHorizontalScrollbar): Invalidate the scrollbar area if hiding it. (WebCore::ScrollView::setHasVerticalScrollbar): Ditto. (WebCore::ScrollView::updateScrollbars): In the case where both scrollbars are going away, compute the scroll corner rect while we still have scrollbars, and then invalidate it explicitly. (updateScrollCorner() doesn't, because it doesn't have access to the old corner rect.) * platform/ScrollableArea.cpp: (WebCore::ScrollableArea::invalidateScrollCorner): Pass the rect in, because we can't compute it in the case where the scrollbars are going away. * platform/ScrollableArea.h: Pass in a rect to invalidateScrollCorner(), which matches invalidateScrollbar(). * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::destroyRootLayer): Pass the corner rect into invalidateScrollCorner(). * rendering/RenderScrollbarPart.cpp: Ditto. (WebCore::RenderScrollbarPart::imageChanged): Ditto. LayoutTests: * compositing/iframes/repaint-after-losing-scrollbars-expected.png: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@96138 268f45cc-cd09-0410-ab3c-d52691b4dbfc
c8bf6391