Bug 129140 – Start fixing the view states driven by the WKScrollView

• Component: New Bugs
• Status: RESOLVED FIXED

[Benjamin Poulain]

Start fixing the view states driven by the WKScrollView

[Benjamin Poulain]

Created attachment 224826 [details]
Patch

[Tim Horton]

Comment on attachment 224826 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=224826&action=review

> Source/WebKit2/UIProcess/API/ios/WKViewIOS.mm:271
> +- (void)_updateContentWindow

"window"?

[Tim Horton]

Comment on attachment 224826 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=224826&action=review

> Source/WebKit2/ChangeLog:8
> +        WKScrollView creates a "window" over WKContentview with an area that is exposed,

capital View

> Source/WebKit2/ChangeLog:9
> +        an area that is unobcured and a certain scale.

typo obscured

> Source/WebKit2/ChangeLog:11
> +        Instead of having 3 loosely related path for updating WKContentView

path*s*

> Source/WebKit2/ChangeLog:12
> +        when the content "window" change, everything is consolidated behind the

"window"?

[Simon Fraser (smfr)]

Comment on attachment 224826 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=224826&action=review

> Source/WebCore/ChangeLog:8
> +
> +

Extra space.

> Source/WebKit2/ChangeLog:8
> +        WKScrollView creates a "window" over WKContentview with an area that is exposed,

over the

> Source/WebKit2/ChangeLog:9
> +        an area that is unobcured and a certain scale.

unobscured and with a certain scale?

> Source/WebKit2/ChangeLog:11
> +        Instead of having 3 loosely related path for updating WKContentView

paths

> Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:384
> +- (void)_updateContentWindow

I think "window" is a bad term to use here; it's too overloaded.

updateViewRects: or updateVisibleRect: would be fine I think.

> Source/WebKit2/UIProcess/API/ios/WKContentView.mm:161
> +    if (oldRoundedPosition != newRoundedPosition)
> +        _page->scrollingCoordinatorProxy()->scrollPositionChangedViaDelegatedScrolling(_page->scrollingCoordinatorProxy()->rootScrollingNodeID(), newRoundedPosition);
> +

It's probably fine to call this when the position didn't actually change?

> Source/WebKit2/UIProcess/API/ios/WKContentView.mm:165
> +        exposedRect.scale(scale);
> +        drawingArea->setExposedRect(exposedRect);

It's not clear why we have to scale this rect; it's already visibleRectInContentCoordinates.

[Benjamin Poulain]

Committed r164466: <http://trac.webkit.org/changeset/164466>