Created attachment 432131 [details] test Noticed this looking at https://developer.apple.com/documentation/coretext/1510813-ctfontgetglyphsforcharacters?language=objc. STR: 1. Open the attached test. 2. Click somewhere in the "Char" of "UniChar". 3. Notice that the line of text wraps (and not all of it gets repainted). Are we incorrectly computing the intrinsic minimum width of the text by not taking into account the word wrap opportunities? Doesn't reproduce with LFC for inline layout turned off.
Yeah, it happens when legacy line layout and IFC disagrees on the layout. According to https://www.w3.org/TR/css-text-3/#white-space-property, white-space: pre -> "Lines only break at forced line breaks; content that does not fit within the block container overflows it." While <wbr> acts as a line breaking opportunity, it is not a forced line break. IFC layout also matches FF. Sadly, clicking on the content forces us to fallback to legacy line layout and it makes the content wrap and we fail to make the containing block taller (as the fallback code only runs the line layout and not the block one) We need to patch legacy line layout.
>Are we incorrectly computing the intrinsic minimum width of the text by not taking into account the word wrap opportunities? The content in inside a fixed width containing block, so we don't really compute intrinsic width here. It's simply about ignoring the soft line break opportunities (<wbr>) and letting the content overflow as specified by the spec.
<rdar://problem/80001586>