Bug 152589 - Remove ScrollView::scrollOffset() in preparation for scrollOffset vs. scrollPosition clarification
Summary: Remove ScrollView::scrollOffset() in preparation for scrollOffset vs. scrollP...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-29 12:29 PST by Simon Fraser (smfr)
Modified: 2015-12-29 16:50 PST (History)
4 users (show)

See Also:

Attachments
Patch (35.41 KB, patch)
2015-12-29 12:31 PST, Simon Fraser (smfr) 		no flags Details | Formatted Diff | Diff
Patch (39.10 KB, patch)
2015-12-29 13:52 PST, Simon Fraser (smfr) 		sam: review+
Details | Formatted Diff | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2015-12-29 12:29:20 PST 
Remove ScrollView::scrollOffset() in preparation for scrollOffset vs. scrollPosition clarification
Comment 1 Simon Fraser (smfr) 2015-12-29 12:31:49 PST 
Created attachment 267989 [details]
Patch
Comment 2 Simon Fraser (smfr) 2015-12-29 13:52:33 PST 
Created attachment 267992 [details]
Patch
Comment 3 Sam Weinig 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.
Comment 4 Simon Fraser (smfr) 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!
Comment 5 Simon Fraser (smfr) 2015-12-29 16:50:20 PST 
https://trac.webkit.org/changeset/194438