Bug 79126 – ScrollingCoordinator::coordinatesScrollingForFrameView should be conditional on compositing being active

• Component: New Bugs
• Status: RESOLVED FIXED

[James Robinson]

ScrollingCoordinator::coordinatesScrollingForFrameView should be conditional on compositing being active

[James Robinson]

Created attachment 127995 [details]
Patch

[Anders Carlsson]

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]

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]

Committed r108392: <http://trac.webkit.org/changeset/108392>