WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
256410
overflow:clip fails when intrusive float is present
https://bugs.webkit.org/show_bug.cgi?id=256410
Summary
overflow:clip fails when intrusive float is present
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
,
alan baradlay
no flags
Details
Formatted Diff
Diff
Patch
(10.22 KB, patch)
2023-05-15 19:44 PDT
,
alan baradlay
ews-feeder
: commit-queue-
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2023-05-12 21:44:18 PDT
<
rdar://problem/109293228
>
alan baradlay
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
alan baradlay
Comment 3
2023-05-13 21:09:07 PDT
Created
attachment 466348
[details]
Patch
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.
alan baradlay
Comment 5
2023-05-15 19:44:59 PDT
Created
attachment 466358
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug