RESOLVED CONFIGURATION CHANGED 249194
Floats on an empty line should still get positioned
https://bugs.webkit.org/show_bug.cgi?id=249194
Summary Floats on an empty line should still get positioned
Ahmad Saleem
Reported 2022-12-12 16:53:37 PST
Hi Team, While going through Blink's commit, I came across another failing test case (from set of two tests), it is failing in Safari 16.1, STP 159 and Firefox Nightly 109, while only Chrome Canary 110 is passing it. Test Case - https://jsfiddle.net/ztmf9k2g/ Blink Commit - https://chromium.googlesource.com/chromium/blink/+/52a70a867a9bb674c261dfe9e69c7fe4feb47adc Just wanted to raise this bug so it can be tracked and if possible to be merged. Thanks!
Attachments
zalan
Comment 2 2022-12-15 19:26:11 PST
Yeah, I think we are good. This is not asserting anymore in WebKit.
Radar WebKit Bug Importer
Comment 3 2022-12-19 16:54:18 PST
Ahmad Saleem
Comment 4 2023-03-03 01:45:46 PST
We are now passing this on WebKit Trunk (261124@main). Just wanted to raise. Appreciate if someone else can also confirm and then we can close this bug. It might be due to Sammy Rendering related fixes or Alan’s Partial Layout fixes.
zalan
Comment 5 2023-03-04 07:01:51 PST
(In reply to Ahmad Saleem from comment #4) > We are now passing this on WebKit Trunk (261124@main). Just wanted to raise. > > Appreciate if someone else can also confirm and then we can close this bug. > It might be due to Sammy Rendering related fixes or Alan’s Partial Layout > fixes. I don't think there's been any work done in this area recently. This bugs is about the float not being placed (ASSERT) which does not reproduce anymore (for a good while) on trunk because of IFC (IFC progression). This test also checks the container height but that assumes the "Ahem" font being installed on the system (30px vs. 33px). -Chrome fails too when "Ahem" is deactivated. Let's close it.
Note You need to log in before you can comment on or make changes to this bug.