commit 4d25b125dae5d2dba69980cae000751efe34b17a
author David Bokan <bokan@chromium.org> Fri Jul 19 02:28:23 2019
committer Commit Bot <commit-bot@chromium.org> Fri Jul 19 02:28:23 2019
tree 6ced3d5c5f8e94d677da45dc9add7505713119eb
parent ee16719e44126b4513cf9865fabc7a04685383da

[BGPT] Make LayoutView the scroll parent of fixed subtrees

A long-standing behavior on the web is that scrolls chaining up from a
position: fixed subtree should chain to the layout viewport. This allows
scrolling a page by mouse wheeling over a position fixed banner.

In BlinkGenPropertyTrees, the scroll tree changed the parenting behavior
for nodes in a fixed subtree. These nodes used to be parented to the
outer/layout viewport but BGPT made them parented to the inner/visual
viewport. This breaks the above chaining behavior since we now try to
scroll the visual viewport when chaining up from a fixed element, rather
than the layout viewport.

This CL changes behavior back to chaining scrolls from fixed content to
the layout viewport. Note that we intentionally don't use the root
scroller since this would mean that an element can chain scrolling to
its sibling as in bug 977954.

Also note that this breaks a small optimization. All descendant
scrollers in a frame (including the frame) that has an element with a
background-attachment:fixed require scrolling on the main thread due to
the fact that we don't implement background-attachment fixed on the
compositor; the background must be repainted on each scroll change.
One exception to this *was* position: fixed scrollers since their
position will never change when an ancestor is scrolled and so we don't
have to repaint the fixed background.

Previously this was done by setting the BackgroundAttachmentFixed
reason on the layout viewport and propagating it down to child scroll
nodes. Before scrolling on the compositor, we check all ancestor scroll
nodes' MainThreadScrollingReasons. Parenting the fixed nodes to the
inner viewport means they would miss having this MTSR set on them. With
this CL they now get the MTSR.

We assume this is a really obscure edge-case and would prefer to avoid
the complexity of keeping this working. If this turns out to regress any
of our metrics, there are some ideas in https://crbug.com/985127.

Bug: 981749,985127
Change-Id: I27a5b42fff257ea7ff86deb5df0fc519a558235c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1707062
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#678956}