useScrollToBottom (user-message-anchor) undershoots on thread load — lands several messages before the last user message
Maintainers usually reply within 1 day
@abhithesys is already working on this.
Since Mar 28, 2026.
Assessment
This issue has not been assessed yet.
Description
Bug Report: useScrollToBottom with user-message-anchor doesn't reach the last user message on thread load
Package versions
@openuidev/react-ui:0.9.20@openuidev/react-headless:0.7.11- React:
19.2.4
Describe the bug
When loading a thread with many messages (via loadThread), the scroll
position lands several messages before the last user message instead of
placing it at the top of the viewport. The user must manually scroll down
to reach the end of the conversation.
The desired behavior — last user message pinned to the top of the
viewport — is correct; it's just not being achieved.
AI Analysis
The user-message-anchor branch in useScrollToBottom (lines 76-89)
does the right thing in principle:
const lastUserMessageDiv = Array.from(
element.querySelectorAll(userMessageSelector)
).pop();
const scrollPosition =
lastUserMessageDiv.getBoundingClientRect().top -
element.getBoundingClientRect().top +
element.scrollTop;
element.scrollTo({ top: scrollPosition, behavior: "smooth" });
The scroll fires in the useEffect on line 93-103 the moment isLoadingMessages flips to false. The issue is that at that point the message components haven't finished laying out — complex content like OpenUI components, Markdown blocks, tool-call accordions, and images are still mounting and expanding. As a result:
getBoundingClientRect() returns stale geometry — the positions are based on partially-rendered content, so the calculated scrollPosition is too low (too far up in the chat).
behavior: "smooth" locks in the stale target — the animated scroll commits to the position computed at call time. As content continues to expand below the measurement point the target becomes increasingly wrong, but smooth scroll doesn't re-evaluate.
Together these cause the scroll to land several messages short of the actual last user message.
Steps to reproduce
- Use Shell.ScrollArea with the default scrollVariant ("user-message-anchor").
- Have a thread with ~20+ messages, ideally containing assistant responses with rich content (OpenUI Renderer output, Markdown with code blocks, tool calls).
- Load the thread (click it in the sidebar → loadThread).
Observe: the viewport lands a few messages above the last user message. Scrolling down manually reveals the remaining messages.
Expected behavior
The last user message should be positioned at the top of the viewport after the thread finishes loading.
- Dominant language
- TypeScript
- Stars
- 10k
- Forks
- 698
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 148
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from thesysdev/openui
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
thesysdev/openui#1445 · 2 comments ·
Maintainers usually reply within 1 day
-
Add dataInvention flag to PromptOptions to disable the 'generate realistic/plausible data' ruleOpen
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
thesysdev/openui#959 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 18/100
Maintainers usually reply within 1 day
All issues in thesysdev/openui
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 2 days
-
reproduced
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
anomalyco/opencode#62052 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
strapi/design-system#2084 ·
Maintainers usually reply within 3 days
-
check:passed streams:remove
Difficulty 1/5 Under an hour Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
OAuth documentation for GET /api/v2/users/me/ appears inconsistent with required global read scopeOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day