Books sometimes ends up with blank pages, especially after adjusting font size
Created attachment 398118 [details] Patch
<rdar://problem/59898144>
Created attachment 398120 [details] Patch
Created attachment 398134 [details] Patch
Created attachment 398138 [details] Patch
Comment on attachment 398138 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=398138&action=review > Source/WebKit/ChangeLog:11 > + - There is a window during page creation where a WKWebView created Maybe don't use the term "window" here. > Source/WebCore/rendering/RenderLayerCompositor.cpp:518 > + if (auto exposedRect = frameView.viewExposedRectInContentCoordinates()) > + visibleRect.intersect(*exposedRect); This doesn't seem right. You're intersecting a rect affected by scrolling with another that is not, and we want to start layer flushing above the layer that scrolls, I think. > Source/WebKit/UIProcess/WebPageProxy.cpp:3786 > + if (m_drawingArea) > + m_drawingArea->didChangeViewExposedRect(); Should this only be called when it changed? > Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:326 > + if (auto exposedRect = m_webPage.mainFrameView()->viewExposedRectInContentCoordinates()) > + visibleRect.intersect(*exposedRect); Same dubious scrolled vs non-scrolled rects. > Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:469 > + if (auto exposedRect = m_webPage.mainFrameView()->viewExposedRectInContentCoordinates()) > + visibleRect.intersect(*exposedRect); Here too.
Super confused now, because the rects that are being intersected are not different... just the timing of the transformation is different. Previously, DrawingArea did the -> contents transform before setting the rect on FrameView.
(In reply to Tim Horton from comment #7) > Super confused now, because the rects that are being intersected are not > different... just the timing of the transformation is different. Previously, > DrawingArea did the -> contents transform before setting the rect on > FrameView. Maybe it's always been wrong but all clients of clips-to-visible also expand the view so that there's not actually any WebCore-visible scrolling?
Gonna need some test apps I guess (or to expand the existing layout tests).
(In reply to Tim Horton from comment #9) > Gonna need some test apps I guess (or to expand the existing layout tests). You are totally right (it was always broken), and it just didn't have any impact in any clients.
Created attachment 398263 [details] Patch
Created attachment 398264 [details] Patch
Comment on attachment 398264 [details] Patch Obviously Simon should review again, too, but this looks great.
Comment on attachment 398264 [details] Patch r+
Committed r261044: <https://trac.webkit.org/changeset/261044> All reviewed patches have been landed. Closing bug and clearing flags on attachment 398264 [details].