Bug 152589

Summary: Remove ScrollView::scrollOffset() in preparation for scrollOffset vs. scrollPosition clarification
Product: WebKit Reporter: Simon Fraser (smfr) <simon.fraser>
Component: New BugsAssignee: Simon Fraser (smfr) <simon.fraser>
Status: RESOLVED FIXED    
Severity: Normal CC: bdakin, simon.fraser, thorton, zalan
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch sam: review+

Simon Fraser (smfr)
Reported 2015-12-29 12:29:20 PST
Remove ScrollView::scrollOffset() in preparation for scrollOffset vs. scrollPosition clarification
Attachments
Patch (35.41 KB, patch)
2015-12-29 12:31 PST, Simon Fraser (smfr) 		no flags
DetailsFormatted DiffDiff
Patch (39.10 KB, patch)
2015-12-29 13:52 PST, Simon Fraser (smfr) 		sam: review+
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Simon Fraser (smfr)
Comment 1 2015-12-29 12:31:49 PST
Created attachment 267989 [details] Patch
Simon Fraser (smfr)
Comment 2 2015-12-29 13:52:33 PST
Created attachment 267992 [details] Patch
Sam Weinig
Comment 3 2015-12-29 14:05:50 PST
Comment on attachment 267992 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=267992&action=review > Source/WebCore/page/FrameView.cpp:2170 > + IntPoint newPosition = scrollPosition(); > + if (oldPosition != newPosition) { > updateLayerPositionsAfterScrolling(); > if (frame().settings().acceleratedCompositingForFixedPositionEnabled()) > updateCompositingLayersAfterScrolling(); > - IntPoint newPosition = scrollPosition(); > - scrollAnimator().setCurrentPosition(scrollPosition()); > + scrollAnimator().setCurrentPosition(newPosition); This subtly changes the logic of this function such that if updateLayerPositionsAfterScrolling() or updateCompositingLayersAfterScrolling() can affect scrollPosition(), the new current position will be different. Are you confident they cannot? > Source/WebCore/svg/SVGSVGElement.cpp:419 > + LayoutPoint scrollOffset = view->scrollPosition(); Given that you are now using a position here, it might make sense to rename the local variable.
Simon Fraser (smfr)
Comment 4 2015-12-29 16:21:35 PST
(In reply to comment #3) > Comment on attachment 267992 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=267992&action=review > > > Source/WebCore/page/FrameView.cpp:2170 > > + IntPoint newPosition = scrollPosition(); > > + if (oldPosition != newPosition) { > > updateLayerPositionsAfterScrolling(); > > if (frame().settings().acceleratedCompositingForFixedPositionEnabled()) > > updateCompositingLayersAfterScrolling(); > > - IntPoint newPosition = scrollPosition(); > > - scrollAnimator().setCurrentPosition(scrollPosition()); > > + scrollAnimator().setCurrentPosition(newPosition); > > This subtly changes the logic of this function such that if > updateLayerPositionsAfterScrolling() or > updateCompositingLayersAfterScrolling() can affect scrollPosition(), the new > current position will be different. Are you confident they cannot? I am!
Simon Fraser (smfr)
Comment 5 2015-12-29 16:50:20 PST
https://trac.webkit.org/changeset/194438
Note You need to log in before you can comment on or make changes to this bug.