Bug 138419 – [EFL] Remove m_scrollPosition from CoordinatedGraphicsScene

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit EFL

[Ryuan Choi]

m_scrollPosition of CoordinatedGraphicsScene is only to adjust fixed element in paintToCurrentGLContext.
But, WebView already know it so we can pass it to paintToCurrentGLContext.

[Ryuan Choi]

Created attachment 241025 [details]
Patch

[Gyuyoung Kim]

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.

[Ryuan Choi]

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.

[WebKit Commit Bot]

Comment on attachment 241025 [details]
Patch

Clearing flags on attachment: 241025

Committed r175692: <http://trac.webkit.org/changeset/175692>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.