Bug 274790

Created attachment 471530 [details] Render of the HTML in Safari 17.5 and Chrome

<rdar://problem/128881044>

Brad, Thanks a lot for the testcase. Very useful. I can confirm this is a regresssion. I'm starting a regression testing.

This has been regressed by bug 261683 https://github.com/WebKit/WebKit/commit/c28da984b5ca8fb4bf7941f1b932dd6dd92c0724

Created attachment 471557 [details] HTML for same underlying bug, but different appearance I’m attaching new HTML that looks like the same underlying bug. This HTML is almost the same, but 1) uses a more “reasonable” line-height and 2) changes the column height slightly. When you open this in Safari 17.5, the drop cap appears entirely in the first column, but there is still an incorrect space in the second column (presumably where WebKit layout thinks the drop cap should appear). I’ll attach screenshots shortly.

Created attachment 471558 [details] Rendering of new HTML in Safari 17.5 and Chrome Here is a comparison of Safari 17.5 and Chrome. I’ve highlighted the incorrect behavior in Safari. And you can see that, in Chrome, the drop cap fits in the first column and doesn’t affect the second column.

Created attachment 471559 [details] Rendering of new HTML in Safari 17.2.1 In this screenshot, you can see the old behavior in Safari. It’s preferable to the current behavior, but this version of Safari deems the drop cap too large to fit in the first column and moves it to the second. It feels like the Chrome behavior is correct (though the old Safari behavior seems justifiable).

Since this regression is a big deal for our application, we were wondering if there is a way to detect this bug and workaround it (until a real fix is available). Is there any way you can tell me how the height for the drop cap is calculated currently (in this broken state)? For instance, I tried getting the bounding rect of the span that contains the drop cap, but that doesn’t equal the height of the letter. I’ve tried to figure out the height by using some combination font-metrics and font-size, but I haven’t figured it out exactly yet (and am worried that might be going down the wrong path). Any advice would be much appreciated!

I don't think there's an easy way to detect this unfortunately. :(

I was afraid you might say that! Oh well. I also found another case (involving widows) that seems related to this bug. To be sure, I’ll attach some example HTML shortly.

Created attachment 471580 [details] Bad layout in second column due to widows If you comment out the “widows: 5” CSS in the attached HTML, you can see that two lines fit below the drop cap. With that “widows: 5”, though, those two lines move to the second column. And while there are five lines in the second column now, the inset due to the (phantom) drop cap persists. In Safari 17.2.1 (and in Chrome), that drop-cap indentation doesn’t appear.

Created attachment 471581 [details] Rendering of bad layout due to widows in Safari 17.5

Thanks a lot for all the test cases. That will help to solve the issue.

The issue in first case appears to be paint, not layout. Overflowing content wrongly paints in the first column while clipping in the second but everything is in a right place.

Basically this used to avoid visual split because the layout was wrong. We pushed the first line on second column down so there was no overflow. Now we have correct layout but the overflowing part shows up on the previous page.

Thanks for taking a look at the first case (https://bug-274790-attachments.webkit.org/attachment.cgi?id=471529). Since that failure is due to an issue with paint, should I file a separate bug? Because the second issue (https://bug-274790-attachments.webkit.org/attachment.cgi?id=471557) feels like it might actually be a layout issue. Lastly, the third issue (https://bug-274790-attachments.webkit.org/attachment.cgi?id=471580) — the one related to widows — must also be different. It’s now fixed in Safari Technology Preview, while the other two cases are not. Apologies for lumping these three cases together. From my perspective, they certainly appeared to be related!

I think we can keep them here for now until I figure out how to handle this.

Comment on attachment 471580 [details] Bad layout in second column due to widows Marking this obsolete, as this no longer happens in Safari 18.1.

Comment on attachment 471581 [details] Rendering of bad layout due to widows in Safari 17.5 Marking this obsolete, as this no longer happens in Safari 18.1.

I obsoleted two attachments, since the case they were hightlighting (see comment #11) no longer occurs in Safari 18.1. However, the issue with the split drop cap still persists in Safari 18.1. You can even see it in Apple Books (version 7.1) on Sequoia 15.1. This does not happen on Ventura, in Apple Books 5.2.

Created attachment 473090 [details] Screenshot of Apple Books 7.1 on Sequoia showing split drop cap