| Summary: | [Legacy line layout] Incorrect wrap position at <wbr> in "white-space: pre" content. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Cameron McCormack (:heycam) <heycam> | ||||
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | NEW --- | ||||||
| Severity: | Normal | CC: | bfulgham, simon.fraser, webkit-bug-importer, zalan | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | WebKit Local Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Cameron McCormack (:heycam)
2021-06-23 21:30:16 PDT
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.
|