Is there an existing issue for this?
Describe the bug
We are observing an issue in Blazor EditForm where oninput does not consistently receive all typed characters when using either:
InputText
Native HTML input
This problem becomes clearly reproducible during rapid typing scenarios, especially when long‑pressing a key (e.g., holding down the "g" key) on a Slow 3G–throttled hosted application.
Because of this behavior, we are unable to capture the actual typed value reliably while the user is typing.
`@using System.ComponentModel.DataAnnotations
<div class="form-group">
<input value="@userModel.Phone"
@oninput="e => userModel.Phone = e.Value?.ToString()" />
</div>
<div>
Email: @userModel.Email <br />
Phone: @userModel.Phone
</div>
@code {
private UserModel userModel = new();
private void OnEmailChanged(string newValue)
{
userModel.Email = newValue;
}
public class UserModel
{
[Required]
public string Email { get; set; }
[Required]
public string Phone { get; set; }
}
}`
Expected Behavior
Expected behavior
- oninput should receive all typed characters
- Model value should reflect the exact user input
- Network latency should not cause character loss
Actual behavior
- Characters are dropped or delayed
- oninput does not reflect the complete typed value
- Model becomes temporarily inconsistent
- Validation and dependent logic behave incorrectly
Steps To Reproduce
Steps to reproduce
- Deploy the app to a hosted environment
- Open browser DevTools → Network tab
- Throttle the network to Slow 3G
- Focus on the input field
- Long‑press any key (e.g., hold "g")
- Observe the bound values displayed below
Exceptions (if any)
We evaluated debouncing as a potential approach, but it does not solve the issue because:
The oninput event itself does not contain all typed characters
Debounce only delays processing; it cannot recover missing input
Our requirement depends on accurate typed values while typing
Therefore, debounce is not a viable solution for this scenario.
This blocks scenarios that require:
- Real‑time typed input processing
- Character‑level validation or detection
- Reliable input handling under slow or unstable networks
Could you please help clarify:
- Is this behavior expected under slow network conditions?
- Is there a recommended Blazor pattern to reliably capture all typed values during oninput?
- Could this be a regression or known limitation in EditForm / InputText?
- Are there any supported alternatives to handle this scenario without losing characters?
Related issues
#14242
#8204
Although these issues are closed, the behavior still appears reproducible in the scenario described above.
.NET Version
10
Anything else?
No response
Is there an existing issue for this?
Describe the bug
We are observing an issue in Blazor EditForm where oninput does not consistently receive all typed characters when using either:
InputText
Native HTML input
This problem becomes clearly reproducible during rapid typing scenarios, especially when long‑pressing a key (e.g., holding down the "g" key) on a Slow 3G–throttled hosted application.
Because of this behavior, we are unable to capture the actual typed value reliably while the user is typing.
`@using System.ComponentModel.DataAnnotations
@code {
private UserModel userModel = new();
}`
Expected Behavior
Expected behavior
Actual behavior
Steps To Reproduce
Steps to reproduce
Exceptions (if any)
We evaluated debouncing as a potential approach, but it does not solve the issue because:
The oninput event itself does not contain all typed characters
Debounce only delays processing; it cannot recover missing input
Our requirement depends on accurate typed values while typing
Therefore, debounce is not a viable solution for this scenario.
This blocks scenarios that require:
Could you please help clarify:
Related issues
#14242
#8204
Although these issues are closed, the behavior still appears reproducible in the scenario described above.
.NET Version
10
Anything else?
No response