Created attachment 371331 [details] Test case to reproduce the issue What steps will reproduce the problem? (1) Load the attached test case What is the expected result? No char is sick out from the green box; all the zero-width chars are ignored and should not affect the height of the line (expected.png) What happens instead? The 3 zero-width class chars are used as forced break points, affecting the height of the line, which sicks out below the green box (actual.png)
Created attachment 371333 [details] Actual result
Created attachment 371334 [details] Expected result
This issue is only reproducible in Mac and iOs platforms, so that means that the bug is in the SimpleLineLayout codepath.
Created attachment 371482 [details] Test case to reproduce the issue
Created attachment 371483 [details] Actual result
After debugging the test case, I've got new information regarding this issue. First of all, this is not affecting the SimpleLineLayout codepath at all, which is not executed if the value of the line-break property is different than 'auto'. Hence, the bug is affecting the BreakingContext path. Additionally, since other ports also use the BreakingContext path, why this bug is not reproducible in WebKitGtk+ ? The reason seems to be that the root cause of this issue is the #196169 bug (maybe duplicated ?) Debugging the attached test case, I've got the following data: * Mac platform - availableWidth (1ch) = 7.796875 - charWidth = 7.80126953 * Gtk platform - availableWidth (1ch) = 8 - charWidth = 8 The consequence of having a charWidth bigger than the availableWidth is that the line breaking logic may have to break just after the char, even that theoretically the single char should fit. Hence, the problem is not related to the line-break: anywhere feature, but more with how WebKit deals with the monospace font and the 'ch' sizing unit.