Able to reproduce the issue on reported version 65.0.3325.181, on latest beta# 66.0.3359.66 and on latest canary 67.0.3386.0 using Windows 10, Ubuntu 14.04 & Mac 10.13.3.

Bisect Info:
=============
Good Build: 64.0.3249.0
Bad Build: 64.0.3250.0

You are probably looking for a change made after 511578 (known good), but no later than 511579 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/8c7e87211aa02c337795f9260705c47d8a277e5b..eeaf4c2326de12c9b36324a805e46ab933057e54

Reviewed-on: https://chromium-review.googlesource.com/735751

@ sunxd: Please confirm the bug and help in re-assigning if it is not related to your change.

Thanks!

I think it's because the fixed-pos layer contributes to the render surface, and the render surface happens to be clipped by masks (instead of applying clip through clip tree), so the fixed pos layer did not bypass mask clips.

We might want to not tile mask layer when render surface has a fixed-pos child.

Is the clip parent of the fixed-position cc::Layer being set correctly?

I think the clip parent is correct:
"LayoutBlockFlow (positioned) DIV class='child'" gets clip parent "LayoutView #document".

That looks correct.

What is different about mask tiling though? why did tiling make it fail?

If I remove opacity:0.99, it can be rendered correctly. I doubt we have the wrong content rect here, and mask tiling uses it to intersect the draw quads mask layer produces, but I need further investigate.

Note: opacity is not required, just a stacking context. Replacing it by
"isolation: isolate" also demonstrates the issue. I think the purpose of the stacking context in the repro is to make the fixed-position layer a "descendant" of the other one.

It looks like the fixed pos element changed the content rect of the render surface (from rect(145, 0, 801, 600) to rect(145, -200, 801, 800), but mask layer's bounds is not changed. We ended up producing mask layer quads that cover rect(145, 0, 801, 800) and missed the top part of the fixed pos element.

I hacked the code by adding a solid color quad (145, -200, 801, 200), the fixed pos element can be rendered correctly with that.

This belongs to the general bug that "composited border radius clip cannot be escaped because it is implemented as a mask". So it is not limited to fixed-pos, anything makes a composited border radius clip could be affected. For example: http://jsbin.com/pesicoguqo/

There was a separate bug with non-tiled mask layer code that when the source render surface is bigger than its mask, the mask's last column/row of pixels will be extended all the way to infinite (i.e. it is sampled using GL_CLAMP_TO_EDGE, without a transparent border.). The tiled mask is not subject to that bug. If you change the example so that the clip-escaping element extends beyond one of the rounded corder, you'll see that everything beyond that corner will be inadvertently clipped even without sunxd@'s patch.

This is a long-standing bug since we ever implemented composited border radius clip. I think it is very difficult to fix with our current compositing architecture. But fear not! Solving this issue is one of the explicit goal of SPv1875 ugh, I mean, BlinkGenPropertyTrees. The example should already render correctly with --enable-blink-gen-property-trees. If everything went as hoped, we will be shipping it next quarter.

Hi trchen@, do you think it's okay that we merge this bug into the general one and let blink-gen-property-trees fix it?

Sure, here's the dupe: https://bugs.chromium.org/p/chromium/issues/detail?id=678669