To handle damage of filtered render passes, SurfaceAggregator treats the entire output_rect of such a pass as damaged whenever anything in the pass's subtree is damaged, and draws the entire output_rect of the pass whenever the intersection between the root damage rect and the output rect is non-empty.

However, this doesn't handle the case where the pass's subtree has no damage and the pass output rect doesn't intersect the root damage rect, but the filter applied to the pass produces output that *does* fall within the damage rect.

For example, when the filter is a reflection (e.g. https://jsfiddle.net/zL8gffy5/11/show), once the original content is scrolled offscreen, if we continue to scroll there's no damage on the filter subtree, and the original content doesn't intersect the root damage rect. So then the RenderPassDrawQuad for the filter gets dropped in SurfaceAggregator::CopyQuadsToPass (https://cs.chromium.org/chromium/src/cc/surfaces/surface_aggregator.cc?rcl=0&l=380) and the (still onscreen) reflection disappears.

The RenderPass itself isn't dropped and still gets drawn in DirectRenderer::DrawRenderPass, but this is wasted work since the RPDQ is dropped.

Possible fixes:
1) Extend the existing workaround (using moved_pixel_passes_) so that the RPDQ doesn't get dropped in CopyQuadsToPass. 
2) Use FilterOperations::MapRect/MapRectReverse to properly propagate rects in the pass tree. 

Both approaches also avoid the inconsistent state of drawing the RenderPass but dropping the RPDQ -- we either drop both or drop neither.

The main downside of (1) is that we'll always draw filtered RPDQs that are onscreen even when they don't intersect the damage rect. This is somewhat mitigated by the fact that we're already always drawing the corresponding render passes. Approach (2) is of course the most correct, so the question is whether the additional complexity of doing this mapping (e.g. mapping the root damage rect step-by-step down the pass tree instead of in a single step from root to pass) is worth it.