Bug 244543

Summary: REGRESSION (iOS 15.6): Composited iframe appears blurry
Product: WebKit Reporter: Simon Fraser (smfr) <simon.fraser>
Component: CompositingAssignee: Matt Woodrow <mattwoodrow>
Status: RESOLVED FIXED    
Severity: Normal CC: baba, graouts, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=241450
https://bugs.webkit.org/show_bug.cgi?id=243949

Simon Fraser (smfr)
Reported 2022-08-30 09:49:07 PDT
Spawned from https://bugs.webkit.org/show_bug.cgi?id=27684#c52: The iframe in this testcase appears blurry: https://jsfiddle.net/vuncxkm0/
Attachments
Radar WebKit Bug Importer
Comment 1 2022-08-30 09:51:17 PDT
Alexey Proskuryakov
Comment 2 2022-08-30 19:17:31 PDT
Per the discussion in bug 27684, this is a regression in iOS 15.6.
Matt Woodrow
Comment 3 2022-08-31 20:31:35 PDT
This is a regression from bug 238589.
Matt Woodrow
Comment 4 2022-09-01 19:35:11 PDT
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
Comment 5 2022-09-01 19:40:24 PDT
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
Comment 6 2022-09-01 21:54:48 PDT
EWS
Comment 7 2022-09-21 20:28:32 PDT
Committed 254746@main (be575e7192ee): <https://commits.webkit.org/254746@main> Reviewed commits have been landed. Closing PR #3948 and removing active labels.
Antoine Quint
Comment 8 2024-06-26 11:59:04 PDT
This fix contributed to bug 272318.
Note You need to log in before you can comment on or make changes to this bug.