[Bug]: Target width input clamps the value on every keystroke
Maintainers usually reply within 1 day
@AnushreeKasturi is already working on this.
Since Oct 17, 2026.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- rust
- Domain
- developer-experience, frontend
Research direction
Read crates/app/src/controls.rs:449-478, especially the target width input handler and its prop:value binding. Reproduce the issue by typing 1000 and check when the displayed value changes. Keep the raw value while typing, clamp on change or blur, and verify that clearing the field still disables target width.
Written by the indexing model from the issue text.
Description
What happened?
The target width input clamps its value on every keystroke. Typing "1000" does not work: after the first character "1" the value is clamped to the minimum (320), and the reactive prop:value binding rewrites the field. The user ends up with a value they did not type.
Steps to reproduce
- Open the app.
- Click the "Target width" input.
- Type 1000 and watch the field.
Expected behavior
The raw typed value stays in the field while typing, and clamping happens on change or blur. Changing the field to empty disables the target width (current behavior, keep it).
Actual behavior
on:input parses and clamps on every keystroke (crates/app/src/controls.rs:466-473), and prop:value immediately writes the clamped value back, producing results like 3200 instead of 1000.
Where did it go wrong?
UI controls / settings
Settings
Not applicable.
Browser
Any.
CodeFrame version
0.7.0
Console output or extra context
Reference: crates/app/src/controls.rs:449-478. Suggested fix: switch to on:change for clamping, or only clamp when the parsed value is out of range and the input is no longer focused.
- Dominant language
- Rust
- Stars
- 1
- Forks
- 0
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 5
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
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 suradet-ps/codeframe
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
suradet-ps/codeframe#40 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
suradet-ps/codeframe#35 ·
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
suradet-ps/codeframe#36 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
suradet-ps/codeframe#38 ·
Maintainers usually reply within 1 day
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
suradet-ps/codeframe#30 ·
Maintainers usually reply within 1 day
All issues in suradet-ps/codeframe
Similar issues
-
test: sim_zero_omega_tests race on shared temp-file names, so two pairs of tests fail at randomOpen
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
pop-os/cosmic-comp#2956 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
area:release criticality:p3 documentation
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
registrystack/registry-stack#2085 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
libp2p/rust-libp2p#6694 ·
Maintainers usually reply within 1 day