Bug 211265 – Books sometimes ends up with blank pages, especially after adjusting font size

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Tim Horton]

Books sometimes ends up with blank pages, especially after adjusting font size

[Tim Horton]

Created attachment 398118 [details]
Patch

[Tim Horton]

<rdar://problem/59898144>

[Tim Horton]

Created attachment 398120 [details]
Patch

[Tim Horton]

Created attachment 398134 [details]
Patch

[Tim Horton]

Created attachment 398138 [details]
Patch

[Simon Fraser (smfr)]

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.

[Tim Horton]

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.

[Tim Horton]

(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?

[Tim Horton]

Gonna need some test apps I guess (or to expand the existing layout tests).

[Tim Horton]

(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.

[Tim Horton]

Created attachment 398263 [details]
Patch

[Tim Horton]

Created attachment 398264 [details]
Patch

[Darin Adler]

Comment on attachment 398264 [details]
Patch

Obviously Simon should review again, too, but this looks great.

[Simon Fraser (smfr)]

Comment on attachment 398264 [details]
Patch

r+

[EWS]

Committed r261044: <https://trac.webkit.org/changeset/261044>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 398264 [details].