fix(scenegraph): ScrollingLabel reports full maxWidth as measured width - #1154
Merged
Conversation
Only the maxWidth was reported to a parent LayoutGroup while text was actively scrolling; once the text fit within maxWidth, the node reported its much narrower actual text width instead. That let a sibling LayoutGroup position later children right after the short text rather than after the reserved column, causing later siblings to render too close to the ScrollingLabel. Roku's own docs specify that horizAlign positions text relative to maxWidth regardless of whether scrolling is active, so the reported measured width is now always the maxWidth-constrained box.
|
5 tasks
lvcabral
added a commit
that referenced
this pull request
Aug 5, 2026
…ical stack (#1158) A hidden Label/ScrollingLabel can carry a stale, non-zero-height bounding rect (set by a forced re-measure while still momentarily visible, e.g. a redundant `label.text = ""` write ahead of `label.visible = false`). LayoutGroup's own child measurement reads that cached rect directly and never checks visibility, unlike the rest of the engine's parent-bounds propagation, so the hidden child's height gets counted toward the stack — pushing a bottom-aligned visible sibling up by a full line height. #1154 removed an incidental width-based gate that used to mask this for ScrollingLabel. Fix LayoutGroup.measureChild to treat an invisible child as zero-size, mirroring Group.nodeRenderingDone's existing visibility guard, instead of special-casing width again.
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
1 participant
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
ScrollingLabel.renderLabelonly reportedmaxWidthas its measured bounding-rect width while text was actively scrolling; when the text fit withinmaxWidthit instead reported the shorter actual text width.LayoutGroupmeasuring that node for positioning purposes then placed later children right after the short text instead of after the reserved column, so they render too close to theScrollingLabel.horizAlignpositions text relative tomaxWidthregardless of whether scrolling is active, so the reported measured width should always be themaxWidth-constrained box, not the actual (possibly shorter) text width.Test plan
npx vitest run test/extensions/scenegraph— 77 files / 791 tests passLayoutGroupregression test reproducing the sibling-positioning bug directly; confirmed it fails without the fix and passes with itnpm run lintcleannpm run prettier:write— no changes needed🤖 Generated with Claude Code