[line-clamp] Fix crash w/ tabs in DoesRemainderFitInLineWithoutEllipsis#58771
Merged
chromium-wpt-export-bot merged 1 commit intomasterfrom Mar 26, 2026
Merged
[line-clamp] Fix crash w/ tabs in DoesRemainderFitInLineWithoutEllipsis#58771chromium-wpt-export-bot merged 1 commit intomasterfrom
chromium-wpt-export-bot merged 1 commit intomasterfrom
Conversation
With the `CSSLineClampLineBreakingEllipsis` feature flag on, the line-clamp ellipsis takes up space when line breaking. This means that if you're line-breaking with an ellipsis, you can't always know if this line would be the last in the paragraph if the ellipsis wasn't there. This is why in https://crrev.com/c/6361775 the `InlineLayoutAlgorithm::DoesRemainderFitInLineWithoutEllipsis` method was added, which iterates through the remaining inline items in the inline FC and adds up their width to figure that out; although in some cases it doesn't have enough information, so it bails out and causes the line breaker to run again without ellipsizing. This method was assuming, however, that non-empty text or control items (other than forced breaks) would always have an associated text shape result. This is mostly the case, but it isn't for preserved tabs, where the shape result is created when line shaping based on the position in the line. This led to a crash in such cases. This CL fixes this by testing whether the shape result is null, and if so, it bails out of the algorithm causing the line breaker to run again. Bug: 40336192, 494630376 Change-Id: I28e2d391c86419ff54f054a5b823c07a794f089d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7689516 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Andreu Botella <abotella@igalia.com> Cr-Commit-Position: refs/heads/main@{#1605427}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-7689516
branch
from
b56a427 to
1487c87
Compare
wpt-pr-bot
approved these changes
Mar 26, 2026
Collaborator
wpt-pr-bot
left a comment
wpt-pr-bot
left a comment
There was a problem hiding this comment.
The review process for this patch is being conducted in the Chromium project.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With the
CSSLineClampLineBreakingEllipsisfeature flag on, theline-clamp ellipsis takes up space when line breaking. This means that
if you're line-breaking with an ellipsis, you can't always know if
this line would be the last in the paragraph if the ellipsis wasn't
there.
This is why in https://crrev.com/c/6361775 the
InlineLayoutAlgorithm::DoesRemainderFitInLineWithoutEllipsismethodwas added, which iterates through the remaining inline items in the
inline FC and adds up their width to figure that out; although in some
cases it doesn't have enough information, so it bails out and causes
the line breaker to run again without ellipsizing.
This method was assuming, however, that non-empty text or control
items (other than forced breaks) would always have an associated text
shape result. This is mostly the case, but it isn't for preserved
tabs, where the shape result is created when line shaping based on the
position in the line. This led to a crash in such cases.
This CL fixes this by testing whether the shape result is null, and if
so, it bails out of the algorithm causing the line breaker to run
again.
Bug: 40336192, 494630376
Change-Id: I28e2d391c86419ff54f054a5b823c07a794f089d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7689516
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Andreu Botella <abotella@igalia.com>
Cr-Commit-Position: refs/heads/main@{#1605427}