Bug 256410

Summary: overflow:clip fails when intrusive float is present
Product: WebKit Reporter: Simon Fraser (smfr) <simon.fraser>
Component: Layout and RenderingAssignee: zalan <zalan>
Status: RESOLVED FIXED    
Severity: Normal CC: bfulgham, changseok, esprehn+autocc, ews-watchlist, glenn, kondapallykalyan, pdr, rbuis, simon.fraser, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: WebKit Local Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch ews-feeder: commit-queue-

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].