Directly Trust Text Layout Width #51206
Closed
Conversation
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
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D74368513 |
c219629 to
f16e0d2
Compare
NickGerleman
added a commit
to NickGerleman/react-native
that referenced
this pull request
May 8, 2025
Summary: When we create a layout from measure constraints, we do some processing of the width, to return a different one, potentially smaller than the layout width, sometimes using line width, and sometimes using the container width. This logic has gotten spooooky over time, and after a series of changes, and bugfixes, now effectively does nothing! 1. Way back in 2020, yungsters made D21056031 introducing this logic to "shrink wrap" text which is wrapped. 2. "Shrink wrapping" is not how web works when text is wrapped, (though it is how it works when there is explicit newline), and facebook#47435 later undid this change 3. facebook#37790 made changes specific to the case of trailing newline, because the logic to "shrink wrap" did not handle correctly. After D74366936, which changes width used for layout creation to correctly respect `Layout.desiredWidth`, we should be back to multiline layouts, with no paragraph whose lines take up more than container width, being "shrink wrapped", while not doing so when there is wrapping or ellipsization, like current behavior. The desired width also excludes the non-visible trailing whitespace. It means we can remove all of this logic, while preserving the same behavior. Mismatched measure widths from those used in the intermediate layout may also result in issues for Facsimile (see example in last diff of stack). Changelog: [Internal] Differential Revision: D74368513
NickGerleman
added a commit
to NickGerleman/react-native
that referenced
this pull request
May 8, 2025
Summary: When we create a layout from measure constraints, we do some processing of the width, to return a different one, potentially smaller than the layout width, sometimes using line width, and sometimes using the container width. This logic has gotten spooooky over time, and after a series of changes, and bugfixes, now effectively does nothing! 1. Way back in 2020, yungsters made D21056031 introducing this logic to "shrink wrap" text which is wrapped. 2. "Shrink wrapping" is not how web works when text is wrapped, (though it is how it works when there is explicit newline), and facebook#47435 later undid this change 3. facebook#37790 made changes specific to the case of trailing newline, because the logic to "shrink wrap" did not handle correctly. After D74366936, which changes width used for layout creation to correctly respect `Layout.desiredWidth`, we should be back to multiline layouts, with no paragraph whose lines take up more than container width, being "shrink wrapped", while not doing so when there is wrapping or ellipsization, like current behavior. The desired width also excludes the non-visible trailing whitespace. It means we can remove all of this logic, while preserving the same behavior. Mismatched measure widths from those used in the intermediate layout may also result in issues for Facsimile (see example in last diff of stack). Changelog: [Internal] Differential Revision: D74368513
f16e0d2 to
49e234c
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D74368513 |
Summary: Pull Request resolved: facebook#51206 When we create a layout from measure constraints, we do some processing of the width, to return a different one, potentially smaller than the layout width, sometimes using line width, and sometimes using the container width. This logic has gotten spooooky over time, and after a series of changes, and bugfixes, now effectively does nothing! 1. Way back in 2020, yungsters made D21056031 introducing this logic to "shrink wrap" text which is wrapped. 2. "Shrink wrapping" is not how web works when text is wrapped, (though it is how it works when there is explicit newline), and facebook#47435 later undid this change 3. facebook#37790 made changes specific to the case of trailing newline, because the logic to "shrink wrap" did not handle correctly. After D74366936, which changes width used for layout creation to correctly respect `Layout.desiredWidth`, we should be back to multiline layouts, with no paragraph whose lines take up more than container width, being "shrink wrapped", while not doing so when there is wrapping or ellipsization, like current behavior. The desired width also excludes the non-visible trailing whitespace. It means we can remove all of this logic, while preserving the same behavior. Mismatched measure widths from those used in the intermediate layout may also result in issues for Facsimile (see example in last diff of stack). Changelog: [Internal] Differential Revision: D74368513
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D74368513 |
49e234c to
4360551
Compare
Contributor
|
This pull request has been merged in 71ef049. |
Collaborator
|
This pull request was successfully merged by @NickGerleman in 71ef049 When will my fix make it into a release? | How to file a pick request? |
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.
Summary:
When we create a layout from measure constraints, we do some processing of the width, to return a different one, potentially smaller than the layout width, sometimes using line width, and sometimes using the container width.
This logic has gotten spooooky over time, and after a series of changes, and bugfixes, now effectively does nothing!
After D74366936, which changes width used for layout creation to correctly respect
Layout.desiredWidth, we should be back to multiline layouts, with no paragraph whose lines take up more than container width, being "shrink wrapped", while not doing so when there is wrapping or ellipsization, like current behavior. The desired width also excludes the non-visible trailing whitespace.It means we can remove all of this logic, while preserving the same behavior. Mismatched measure widths from those used in the intermediate layout may also result in issues for Facsimile (see example in last diff of stack).
Changelog: [Internal]
Differential Revision: D74368513