Bug 79126

Summary: ScrollingCoordinator::coordinatesScrollingForFrameView should be conditional on compositing being active
Product: WebKit Reporter: James Robinson <jamesr>
Component: New BugsAssignee: James Robinson <jamesr>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, andersca, enne, nduca, vangelis
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch andersca: review+

James Robinson
Reported 2012-02-21 10:40:08 PST
ScrollingCoordinator::coordinatesScrollingForFrameView should be conditional on compositing being active
Attachments
Patch (3.81 KB, patch)
2012-02-21 10:42 PST, James Robinson 		andersca: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
James Robinson
Comment 1 2012-02-21 10:42:42 PST
Created attachment 127995 [details] Patch
Anders Carlsson
Comment 2 2012-02-21 10:57:16 PST
Comment on attachment 127995 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=127995&action=review > Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:-205 > + setScrollLayer(scrollLayerForFrameView(frameView)); > frameViewLayoutUpdated(frameView); > recomputeWheelEventHandlerCount(); > updateShouldUpdateScrollLayerPositionOnMainThread(); > - setScrollLayer(scrollLayerForFrameView(frameView)); This change isn't mentioned in the change log; why is it needed?
James Robinson
Comment 3 2012-02-21 12:28:54 PST
That slipped into this patch by accident. The idea is to initialize the scroll layer before anything else because in Chromium we're buffering properties on the layer, not on a separate data structure. This raises an interesting question about what happens when calls are made in a different order - for example, if something calls frameViewWheelEventHandlerCountChanged() before frameViewRootLayerDidChange() should it behave the same as if the calls were made in the reverse order or not? Today in the mac implementation it seems that this would vary depending on whether the sync timer fires or not between the calls, although with the way the callsites are coded I don't think it makes a difference.
James Robinson
Comment 4 2012-02-21 13:38:43 PST
Committed r108392: <http://trac.webkit.org/changeset/108392>
Note You need to log in before you can comment on or make changes to this bug.