fix(ui): reset message textarea height after sending - #221
Merged
Conversation
Typing a multi-line message auto-grows the textarea via scrollHeight, but after hitting Enter to send, the textarea stayed expanded instead of shrinking back to one line. The `auto_resize()` call inside `send_message` ran synchronously right after `message_text.set(String::new())`. Dioxus hasn't flushed the signal change to the DOM yet at that point, so `scrollHeight` still reflects the pre-send (expanded) content, and the resize computes the old height. Defer the resize via `crate::util::defer()` so it runs on the next tick after Dioxus has cleared the textarea's `value`. Also pulled the resize logic into a free function — it captures nothing from the component, and making it a plain `fn` avoids move-of-closure issues when passing it to `defer`. Verified in a local browser: 44px initial → 140px with 5-line message → 44px after send. [AI-assisted - Claude] Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Covers #221. Verified the test fails against the pre-fix code (height stays at 140px after Enter-to-send) and passes across all 5 Playwright projects (chromium, firefox, webkit, mobile-chrome, mobile-safari) with the defer-based fix in place. [AI-assisted - Claude] Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
constant_time_eq 0.4.3 was published 2026-04-18 and requires rustc 1.95.0, but rust-toolchain.toml pins rustc to 1.94.1 to keep WASM hashes deterministic (see the comment in that file). Without a committed Cargo.lock, every fresh CI build picked up 0.4.3 and failed at dependency check with "requires rustc 1.95.0". Pin constant_time_eq to 0.4.2 in both the build and ui-playwright-tests jobs before running cargo make. Long-term fix is to either bump the toolchain (requires delegate migration) or commit Cargo.lock; both are out of scope for this PR. [AI-assisted - Claude] Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced Jul 29, 2026
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
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.
Problem
Typing a multi-line message auto-grows the textarea (height follows
scrollHeight, capped at 168px), but after hitting Enter to send, the textarea stayed at its expanded height instead of shrinking back to a single line. The message was cleared, but the input bar took up 4+ lines of empty space until the user typed again.Approach
The
auto_resize()call insidesend_messageran synchronously immediately aftermessage_text.set(String::new()). Dioxus hasn't flushed the signal change to the DOM yet at that point, soscrollHeightstill reflects the pre-send (expanded) content, and the resize computes the old height.Fix: defer the resize via
crate::util::defer()(our wrapper aroundsetTimeout(0)that also pushes the Dioxus runtime + root scope) so it runs on the next tick, after Dioxus has propagated the cleared value to the textarea's DOM.Also pulled the resize logic into a free function. It captures nothing from the component, and making it a plain
fnavoids move-of-closure issues when passing it todefer.Testing
Manually verified in a local browser against
cargo make build-ui-example-no-sync:cargo fmt+cargo clippy -p river-ui --target wasm32-unknown-unknown --features no-syncclean for the touched file.Only UI code changed — no delegate or contract WASM impact, no migration entry needed.
[AI-assisted - Claude]