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-

Simon Fraser (smfr)
Reported 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
Attachments
Patch (9.73 KB, patch)
2023-05-13 21:09 PDT, zalan
no flags
Patch (10.22 KB, patch)
2023-05-15 19:44 PDT, zalan
ews-feeder: commit-queue-
Radar WebKit Bug Importer
Comment 1 2023-05-12 21:44:18 PDT
zalan
Comment 2 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
zalan
Comment 3 2023-05-13 21:09:07 PDT
Simon Fraser (smfr)
Comment 4 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.
zalan
Comment 5 2023-05-15 19:44:59 PDT
EWS
Comment 6 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].
Note You need to log in before you can comment on or make changes to this bug.