Bug 256410 - overflow:clip fails when intrusive float is present
Summary: overflow:clip fails when intrusive float is present
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: zalan
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2023-05-05 21:43 PDT by Simon Fraser (smfr)
Modified: 2023-05-15 23:26 PDT (History)
11 users (show)

See Also:


Attachments
Patch (9.73 KB, patch)
2023-05-13 21:09 PDT, zalan
no flags Details | Formatted Diff | Diff
Patch (10.22 KB, patch)
2023-05-15 19:44 PDT, zalan
ews-feeder: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2023-05-05 21:43:28 PDT
As noted here: https://github.com/w3c/csswg-drafts/issues/8607#issuecomment-1533932813

"First, in Safari, the test doesn't work, because it seems that overflow: clip stops having any effect at all (!) if a float overflows in the block axis. It would take effect in the inline axis if there was no block overflow, or if any block axis overflow was caused by something other than a float, like an abspos. Hard to think that's anything but a bug, but that bug could be a sign of "it's harder than we thought"."

Test case at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=11611
Comment 1 Radar WebKit Bug Importer 2023-05-12 21:44:18 PDT
<rdar://problem/109293228>
Comment 2 zalan 2023-05-13 13:55:26 PDT
intrusive floats like this don't get clipped by their containing block (or ancestors all the way to where they end up being intrusive) because we paint them out of the normal paint order (see RenderBlockFlow::paintFloats), so by the time we get to paint them, clipping is gone.
Probably RenderBlockFlow::paintFloats should apply clipping by looking at the ancestor chain of these intrusive floats.

should read the spec first (always), but with overflow: clip, layout and paint could get very disconnected when intrusive floats are involved due to the fact that unlike overflow: hidden, clip does not establish a formatting context. such intrusive floats can impact the position of other, inline level and/or float avoider boxes and yet in the final rendering they look like as if some invisible force pushed them away.
e.g.

<style>
.clip {
  width: 50px;
  height: 50px;
}

.float {
  width: 500px;
  height: 100px;
  float: left;
}

</style>
<div class=clip>
  <div class=float></div>
</div>
<div>
  this line is constrained by the intrusive but yet clipped float
</div

will produce something like this:

   .clip
 ___________
|          |*******************************
|  .float  |                              *
|          |                              *
|__________|   clipped out part           *
 *                                        *this line is constrained by the intrusive but yet clipped float
 ******************************************

where the '*' part is hidden.

 ___________
|          |
|          |                              
|          |                              
|__________|           
                                           this line is constrained by the intrusive but yet clipped float
Comment 3 zalan 2023-05-13 21:09:07 PDT
Created attachment 466348 [details]
Patch
Comment 4 Simon Fraser (smfr) 2023-05-15 15:05:52 PDT
Comment on attachment 466348 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=466348&action=review

> Source/WebCore/rendering/FloatingObjects.cpp:56
> +    , m_overflowClippedByAncestor(false)

maybe `m_hasAncestorWithOverflowClip`. Also, we can initialize bitfield members with initializers now.
Comment 5 zalan 2023-05-15 19:44:59 PDT
Created attachment 466358 [details]
Patch
Comment 6 EWS 2023-05-15 21:59:14 PDT
Committed 264101@main (a5ba024da4f4): <https://commits.webkit.org/264101@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 466358 [details].