Start fixing the view states driven by the WKScrollView
Created attachment 224826 [details] Patch
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"?
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"?
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.
Committed r164466: <http://trac.webkit.org/changeset/164466>