Bug 244543 – REGRESSION (iOS 15.6): Composited iframe appears blurry

• Status: RESOLVED
• Resolution: FIXED
• Component: Compositing

[Simon Fraser (smfr)]

Spawned from https://bugs.webkit.org/show_bug.cgi?id=27684#c52:

The iframe in this testcase appears blurry: https://jsfiddle.net/vuncxkm0/

[Radar WebKit Bug Importer]

<rdar://problem/99335877>

[Alexey Proskuryakov]

Per the discussion in bug 27684, this is a regression in iOS 15.6.

[Matt Woodrow]

This is a regression from bug 238589.

[Matt Woodrow]

I believe this is the inverse of the problem that bug 238589 fixed.

The case there was that we didn't push a compositing container for the parent of the negative z-index element, and thus anything we contributed to the overlap map from within the negative z-index element got stored in the wrong compositing scope.

The fix was to speculative create a compositing scope for the container, assuming that we'll need it (because of a negative z-index element that requires compositing), and thus any contributed overlap goes to the right place.

Unfortunately in the case where none of the z-index elements require compositing, we don't need the compositing scope so we pop the speculative one for the container. However now we have the reverse issue, where again any contributed overlaps have gone to the wrong compositing scope.

[Matt Woodrow]

I'm thinking of duplicating the OverlapMap for this case, where one has the speculative container pushed and one doesn't. All calls to mutate the OverlapMap while in this state get sent to both, and when we're done with negative z-index element we can pick the one that was correct to move forward with.

The hardest part to handle with this is what do with calls that read from the OverlapMap, since we have two sources and don't yet know which is correct.

It looks like the only relevant getter is 'overlapsLayers'.

I believe the topmost OverlapMapContainer should always be empty (and thus overlapsLayer will return false), unless we've pushed a further compositing scope and then popped it again.

If that has happened, then we must have found a compositing layer, and we must be keeping the OverlapMap with the speculative container pushed.

Thus, it's always ok to read from that one, since they're either both empty, or it's the correct one.

[Matt Woodrow]

Pull request: https://github.com/WebKit/WebKit/pull/3948

[EWS]

Committed 254746@main (be575e7192ee): <https://commits.webkit.org/254746@main>

Reviewed commits have been landed. Closing PR #3948 and removing active labels.

[Antoine Quint]

This fix contributed to bug 272318.