Introducing a regular clip inside a sticky clip results in bad behaviour and stack overflow

[staktrace]

Run the scrolling.rs example, and scroll the nested frame. Observe how the dark blue rect (which is initially not visible, but becomes visible as you scroll the nested frame down) behaves. In particular, it is sticky at two different ranges, once when it is near the bottom of the nested scroll frame, and once more when it is near the top of the nested scroll frame.

Now apply this patch, which just introduces a single clip inside the sticky frame. Note that the clip rect is the same as the bounds of the rect inside the sticky frame, so this clip should have no visual effect.

diff --git a/webrender/examples/scrolling.rs b/webrender/examples/scrolling.rs
index d335206b..f9747c03 100644
--- a/webrender/examples/scrolling.rs
+++ b/webrender/examples/scrolling.rs
@@ -116,18 +116,21 @@ impl Example for App {
                     Some(StickySideConstraint {
                         margin: 10.0,
                         max_offset: -40.0,
                     }),
                     None,
                 ),
             );
             builder.push_clip_id(sticky_id);
+            let dummy_clip = builder.define_clip(None, (50, 350).by(50, 50), vec![], None);
+            builder.push_clip_id(dummy_clip);
             let info = LayoutPrimitiveInfo::new((50, 350).by(50, 50));
             builder.push_rect(&info, ColorF::new(0.5, 0.5, 1.0, 1.0));
+            builder.pop_clip_id(); // dummy_clip
             builder.pop_clip_id(); // sticky_id

             // just for good measure add another teal square further down and to
             // the right, which can be scrolled into view by the user
             let info = LayoutPrimitiveInfo::new((250, 350).to(300, 400));
             builder.push_rect(&info, ColorF::new(0.0, 1.0, 1.0, 1.0));

             builder.pop_clip_id(); // nested_clip_id

Build with this and scroll. Observe how (a) the rect doesn't stick any more and (b) if you scroll far enough the app crashes with this:

thread 'RenderBackend' has overflowed its stack
fatal runtime error: stack overflow

Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

/cc @mrobinson

[staktrace]

Looks like the overflow is due to infinite recursion in RenderTaskTree::max_depth

[kvark]

I'm getting a different result:

thread 'RenderBackend' panicked at 'assertion failed: (left == right)
left: FrameId(21),
right: FrameId(22)', src/gpu_cache.rs:594:8
note: Run with RUST_BACKTRACE=1 for a backtrace.
thread 'main' panicked at 'called Result::unwrap() on an Err value: Error { repr: Custom(Custom { kind: Other, error: StringError("cannot send on closed channel") }) }', /checkout/src/libcore/result.rs:860:4

Which corresponds to

debug_assert_eq!(block.last_access_time, self.frame_id);