radzenhq/radzen-blazor

Advanced Numeric Filter does not register input in special case

kerajel opened this issue · 2 comments

The issue is reproduced only on hosted environment (that is, not reproduced when the application runs locally in debug e.g. launched from Visual Studio)
The issue is reproduced only on numeric advanced filter (integers, decimals alike)

Preconditions
RadzenDataGrid with LoadData and advanced filtering
The LoadData has a dialog service that shows current LoadDataArgs's filter:

public override async Task LoadData(LoadDataArgs loadDataArgs)
{
	await DialogService.Alert($"{loadDataArgs.Filter}");
	
	entries = await GetEntries();
	totalCount = await GetTotalCount();
}

When I enter a numeric input and press 'Apply' right away then my input is not registered in the LoadDataArgs.Filter. Here is a gif that showcases that:
NoClickAway

But when I enter the same numeric input and click away from the input (e.g. on the area near the second filter) then my input is registered in LoadDataArgs.Filter. Here is a gif that showcases that:
ClickAway

I have not observed such behavior around 2 weeks ago, so it must be related to the recent changes. Access to the website where this is observed can be granted if it helps.

.NET 9.0
Radzen.Blazor Version="5.6.7"
Google Chrome Version 131.0.6778.86 (Official Build) (64-bit)
Hosting: SmarterAsp.NET

We cannot provide any advice by looking at a gif. Use our source code to debug your app.

@enchev my app is fine, it's the numeric filter component that requires debugging.

I have skimmed last weeks' commits and found this particular one: 124033d#diff-7ad12b64ebe222b4a5a33c2735cbd89d58bac88807d49ffb3c5a23ffb41357a8L818

In scope of this commit the oninput handler was removed. By removing this event handler, the numeric input field now relies on the default onchange event, which only fires when the input loses focus, matching my observations.

I can additionally confirm that this commit broke the input by downgrading to 5.6.0 - before the commit - the issue is not observed on this version.

Although removing of the handler introduced the current problem it has fixed the previous issue I had reported
#1787