Bug 199260 – Rotated composited elements with clipping descendants sometimes don't respecting original layering

• Status: NEW
• Component: Compositing

Created attachment 373005 [details]
Minimal reproduction case

Overview:
Ele
Drag-selecting any page crashes Mac builds in the NSGetFactory function.
Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps.

Steps to reproduce:
1) Open the attached html in chrome or safari.
2) Open inspector tools and select div with 'object' class.
3) Change object's transform property function 'rotate' to use various angles.
3) Observe div elements with class names 'element-1' and 'element-2'.

Expected results:
The layering of most inner elements should be the same regardless of the rotation angle of their parent.

Actual Results:
With some angles used in rotate function the innermost div elements are correctly layered while with others they are not.

Hardware and browsers:
Mac OS 10.13.3
Chrome Version 75.0.3770.100 (Official Build) (64-bit)
Safari Version 11.0.3 (13604.5.6)

Additional Builds and Platforms:
Safari on Iphone 7 with iOS 12.3.1
Chrome Version 75.0.3770.100 (Official Build) (64-bit) on Windows 10

Additional Information:

Experimenting with the minimal reproduction case we figured out

Seems I accidentally submitted this too soon.

Overview:

Layering of elements within rotated parent with overflow hidden is not respected when one of the elements is sent to GPU.

Experimenting with the attached minimal reproduction case we figured out that the combination of overflow: hidden on element 'container' class, rotated element with class 'object' and sending one of the elements within 'container' element produces this result. Sending all elements within 'container' element will fix this issue.

[Radar WebKit Bug Importer]

<rdar://problem/52269393>

[Alexey Proskuryakov]

The test case shows a green square on my iPhone. Does that mean that the test passes?

[Simon Fraser (smfr)]

Please attach a test case that shows both "good" and "bad" states. I should not have to go messing in the inspector to reproduce the bug.

[Simon Fraser (smfr)]

Created attachment 373037 [details]
Better testcase

[Simon Fraser (smfr)]

Created attachment 373049 [details]
Correct testcase

[Simon Fraser (smfr)]

In the bad case we're not detecting that the blue box needs compositing because overlap testing fails.

[Simon Fraser (smfr)]

In RenderLayerCompositor::addToOverlapMap(), 'clipRect' seems wrong, and then we intersect it with clippedBounds and get a rect that is too small.

[Simon Fraser (smfr)]

RenderLayer::calculateClipRects() just offsets the clip rect by renderer().localToContainerPoint(FloatPoint(), &clipRectsContext.rootLayer->renderer()), which is clearly wrong with rotations.

[Simon Fraser (smfr)]

Created attachment 373052 [details]
Testcase

[Ahmad Saleem]

I am able to reproduce this bug in Safari 16, Safari Technology Preview 156 and it does not show "blue" in second "green" square. All other browsers (Chrome Canary 109 and Firefox Nightly 108) show both "blue" square within "green" squares. Just wanted to update results. Thanks!