m_scrollPosition of CoordinatedGraphicsScene is only to adjust fixed element in paintToCurrentGLContext. But, WebView already know it so we can pass it to paintToCurrentGLContext.
Created attachment 241025 [details] Patch
Comment on attachment 241025 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=241025&action=review > Source/WebKit2/UIProcess/CoordinatedGraphics/CoordinatedLayerTreeHostProxy.cpp:-77 > - const FloatPoint& scrollPosition = rect.location(); Is this scrollPosition same with contentPosition which is used by this patch ? I think this patch should pass WKViewRestoreZoomAndScrollBackForward unit test at least.
Comment on attachment 241025 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=241025&action=review >> Source/WebKit2/UIProcess/CoordinatedGraphics/CoordinatedLayerTreeHostProxy.cpp:-77 >> - const FloatPoint& scrollPosition = rect.location(); > > Is this scrollPosition same with contentPosition which is used by this patch ? I think this patch should pass WKViewRestoreZoomAndScrollBackForward unit test at least. Sure, scroll API such as EwkView::scrollBy update m_contentPosition via WKViewSetContentPosition and calls setVisibleContentRect via didChangeContentsVisibility. If these are different, fixed elements will be drawn at wrong coordination. And I tested WKViewRestoreZoomAndScrollBackForward and WKViewScrollTo and both tests are fine.
Comment on attachment 241025 [details] Patch Clearing flags on attachment: 241025 Committed r175692: <http://trac.webkit.org/changeset/175692>
All reviewed patches have been landed. Closing bug.