Advanced Numeric Filter Second Input Issue #1508

New Issue

claunia · 2026-01-29T17:54:40Z

claunia commented

2026-01-29 17:54:40 +00:00

Originally created by @kerajel on GitHub (Dec 1, 2024).

This is reopen of https://github.com/radzenhq/radzen-blazor/issues/1817 ('Reproduced on Hosted Environment' section), the commit 1f9e5cfa42a656cca436d7da6eb9a51e3458395 fixed the issue on demo, but on the hosted environment it is still the same.

The second input's value is not registered unless the filter frame is focused by clicking on it prior to clicking 'Apply', however the previous fixes solved the similar issue for the first input.

It is actually possible to see that right after the 'Apply' button is pressed, the value in the second input simply disappears (unless the frame was focused), and only then filter proceeds to filter.

Radzen.Blazor Version=5.6.10

Originally created by @kerajel on GitHub (Dec 1, 2024). This is reopen of https://github.com/radzenhq/radzen-blazor/issues/1817 ('Reproduced on Hosted Environment' section), the commit [1f9e5cfa42a656cca436d7da6eb9a51e3458395 ](https://github.com/radzenhq/radzen-blazor/commit/11f9e5cfa42a656cca436d7da6eb9a51e3458395#diff-cbd19b239edeafb4b8e1912a75185329b3c2b72eaa0410fcf81f3719e155430cR346)fixed the issue on demo, but on the hosted environment it is still the same. The second input's value is not registered unless the filter frame is focused by clicking on it prior to clicking 'Apply', however the previous fixes solved the similar issue for the first input. It is actually possible to see that right after the 'Apply' button is pressed, the value in the second input simply disappears (unless the frame was focused), and only then filter proceeds to filter. Radzen.Blazor Version=5.6.10

claunia closed this issue

2026-01-29 17:54:40 +00:00

claunia commented

2026-01-29 17:54:41 +00:00

@kerajel commented on GitHub (Dec 1, 2024):

@enchev, unfortunately this did not help, value in the second input keeps disappearing.

I have put together a simple application (created from template in Radzen Studio) - it's single pager with single data grid wired to a LoadData event, nothing else: http://dmaltepebotov-001-site2.qtempurl.com/

It's easy to replicate the behavior - filter by 'Id' - 10000 first input OR 10001 second input, click apply right away, only 10000 is returned.

Here is git repo of this application https://github.com/kerajel/RadzenDebugSite

Hopefully that would help

@kerajel commented on GitHub (Dec 1, 2024): @enchev, unfortunately this did not help, value in the second input keeps disappearing. I have put together a simple application (created from template in Radzen Studio) - it's single pager with single data grid wired to a LoadData event, nothing else: http://dmaltepebotov-001-site2.qtempurl.com/ It's easy to replicate the behavior - filter by 'Id' - 10000 first input OR 10001 second input, click apply right away, only 10000 is returned. Here is git repo of this application https://github.com/kerajel/RadzenDebugSite Hopefully that would help

claunia commented

2026-01-29 17:54:41 +00:00

@enchev commented on GitHub (Dec 2, 2024):

This is what I see using modified version of your demo since we don't have access to your database. The app is exposed publicly using ngrok to simulate the real Blazor hosting:

https://github.com/user-attachments/assets/85e13d28-c1d4-44e2-b3c1-7601c416da62

@enchev commented on GitHub (Dec 2, 2024): This is what I see using modified version of your demo since we don't have access to your database. The app is exposed publicly using ngrok to simulate the real Blazor hosting: ![image](https://github.com/user-attachments/assets/c08eb230-a83e-4ad2-b9e7-78456221c9ec) https://github.com/user-attachments/assets/85e13d28-c1d4-44e2-b3c1-7601c416da62

claunia commented

2026-01-29 17:54:41 +00:00

@kerajel commented on GitHub (Dec 2, 2024):

@enchev, I have updated the http://dmaltepebotov-001-site2.qtempurl.com/ stand with your code and I still observe the behavior where value disappears. Did you use a real hosting or does ngrok simply point to your localhost?

@kerajel commented on GitHub (Dec 2, 2024): @enchev, I have updated the http://dmaltepebotov-001-site2.qtempurl.com/ stand with your code and I still observe the behavior where value disappears. Did you use a real hosting or does ngrok simply point to your localhost? ![Recording 2024-12-02 124340](https://github.com/user-attachments/assets/67dfee82-ec2a-4404-bac9-e69322b2b168)

claunia commented

2026-01-29 17:54:41 +00:00

@enchev commented on GitHub (Dec 2, 2024):

https://github.com/user-attachments/assets/287313b4-e72b-41d7-b21e-fc80059d15db

@enchev commented on GitHub (Dec 2, 2024): https://github.com/user-attachments/assets/287313b4-e72b-41d7-b21e-fc80059d15db

claunia commented

2026-01-29 17:54:41 +00:00

@kerajel commented on GitHub (Dec 2, 2024):

@enchev, I tried multiple times and around 30% tries I was able to get it working, but generally the value keeps disappearing.

It might be related to the fact that the hosting is located around Eastern Europe which works better for you (and resemble local host behavior) and worse for me (whereas I am located closed to Western Asia)

However the JS script was supposed to fix that, I am surprised that it works differently for first and second filter inputs.

@kerajel commented on GitHub (Dec 2, 2024): @enchev, I tried multiple times and around 30% tries I was able to get it working, but generally the value keeps disappearing. It might be related to the fact that the hosting is located around Eastern Europe which works better for you (and resemble local host behavior) and worse for me (whereas I am located closed to Western Asia) However the JS script was supposed to fix that, I am surprised that it works differently for first and second filter inputs.

claunia commented

2026-01-29 17:54:42 +00:00

@enchev commented on GitHub (Dec 2, 2024):

Maybe it will be wise if you switch to Blazor WebAssembly to avoid such problems related to internet speed and Blazor server lag.

@enchev commented on GitHub (Dec 2, 2024): Maybe it will be wise if you switch to Blazor WebAssembly to avoid such problems related to internet speed and Blazor server lag.

claunia commented

2026-01-29 17:54:42 +00:00

@kerajel commented on GitHub (Dec 2, 2024):

@enchev

Honestly, I don't believe there's a problem with internet speed—I've tested it on a 60mbps wired connection and on 4G mobile. My colleague 1500 km away confirms the same observations. Moreover, according to global statistics, my location has a better internet connection than 70% of the world's population. So, if we were to blame the issues solely on internet speed, it would imply that by design, Server Blazor wouldn't be usable by 70% of the world, which is clearly not the case.

I also doubt that the issue is related to "Blazor lag," a term we've started using. I've added JavaScript console logs to observe the raw values of each input before clicking the 'Apply' button, and they were correct every time. The DOM reflects the correct values, but the component fails to pick up the current version unless something else is focused. This occurs only with numeric inputs; I've never reproduced it with text inputs, suggesting that the problem is specific to certain component.

Having said all that, changing onmousedown="this.focus()" to onmousedown="event.preventDefault(); this.dispatchEvent(new KeyboardEvent('keydown', {bubbles: true, cancelable: true, keyCode: 9}));" has completely resolved the issue. I tested it throughout the day, and it worked flawlessly each time. I do not imply that this is a production-ready solution, however it must be the key to understand why this happens in the first place.

Unfortunately, the same trick did not work for the issue reported at https://github.com/radzenhq/radzen-blazor/issues/1818.

@kerajel commented on GitHub (Dec 2, 2024): @enchev Honestly, I don't believe there's a problem with internet speed—I've tested it on a 60mbps wired connection and on 4G mobile. My colleague 1500 km away confirms the same observations. Moreover, according to global statistics, my location has a better internet connection than 70% of the world's population. So, if we were to blame the issues solely on internet speed, it would imply that by design, Server Blazor wouldn't be usable by 70% of the world, which is clearly not the case. I also doubt that the issue is related to "Blazor lag," a term we've started using. I've added JavaScript console logs to observe the raw values of each input before clicking the 'Apply' button, and they were correct every time. The DOM reflects the correct values, but the component fails to pick up the current version unless something else is focused. This occurs only with numeric inputs; I've never reproduced it with text inputs, suggesting that the problem is specific to certain component. **Having said all that**, changing ```onmousedown="this.focus()"``` to ```onmousedown="event.preventDefault(); this.dispatchEvent(new KeyboardEvent('keydown', {bubbles: true, cancelable: true, keyCode: 9}));"``` has completely resolved the issue. I tested it throughout the day, and it worked flawlessly each time. I do not imply that this is a production-ready solution, however it must be the key to understand why this happens in the first place. Unfortunately, the same trick did not work for the issue reported at https://github.com/radzenhq/radzen-blazor/issues/1818.

claunia commented

2026-01-29 17:54:42 +00:00

@enchev commented on GitHub (Dec 3, 2024):

Blazor server latency is a serious problem and might completely destroy your app scalability and introduce serious issues on both your server and user experience - we are dealing with such problems since 2019 when we started our Blazor offering. In the beginning our demos were Blazor Server and this caused us multiple problems every week, once we switched to WASM all problems went away. Not to mention the hosting cost especially on Azure, still I'll test the proposed code to check if we can integrate it.

@enchev commented on GitHub (Dec 3, 2024): Blazor server latency is a serious problem and might completely destroy your app scalability and introduce serious issues on both your server and user experience - we are dealing with such problems since 2019 when we started our Blazor offering. In the beginning our demos were Blazor Server and this caused us multiple problems every week, once we switched to WASM all problems went away. Not to mention the hosting cost especially on Azure, still I'll test the proposed code to check if we can integrate it.

claunia commented

2026-01-29 17:54:42 +00:00

@kerajel commented on GitHub (Dec 3, 2024):

@enchev, thank you!

I think I understand the general problem - the numeric inputs (in the Advanced Numeric Filter and in RadzenDataFilter in https://github.com/radzenhq/radzen-blazor/issues/1818) utilize the 'onchange' event which does by design require a user to finish the input and focus away (or press Enter).

And we can't use the 'oninput' event because of formatting & validation, the formatted value overwrites the latest raw input value and might interfere with whatever a user typed in after. (otherwise the 'oninput' captures the value as expected)

However, clicking the filter's 'Apply' button does not provide a guaranteed 'commit' of the input by triggering the 'onchange' event. If it did, that would've probably resolve it.

And in case of https://github.com/radzenhq/radzen-blazor/issues/1818 whatever action that would like to receive the result of ToFilterString() should ensure that all related numeric inputs on the page have 'committed' by invoking it manually. I tried something like this but I could not get it to work reliably:

<RadzenButton 
    Text="Apply"
    Click="RadzenDataFilter"
    onmousedown="
        var inputs = document.querySelectorAll('.rz-numeric-input');
        inputs.forEach(function(input) {
            input.focus();
            console.log('Focused: ' + input.className + ', Value: ' + input.value); // value is always as expected
            var changeEvent = new Event('change', { bubbles: true });
            input.dispatchEvent(changeEvent);
        });
    "
/>

@kerajel commented on GitHub (Dec 3, 2024): @enchev, thank you! I think I understand the general problem - the numeric inputs (in the Advanced Numeric Filter and in RadzenDataFilter in https://github.com/radzenhq/radzen-blazor/issues/1818) utilize the 'onchange' event which does by design require a user to finish the input and focus away (or press Enter). And we can't use the 'oninput' event because of formatting & validation, the formatted value overwrites the latest raw input value and might interfere with whatever a user typed in after. (otherwise the 'oninput' captures the value as expected) However, clicking the filter's 'Apply' button does not provide a guaranteed 'commit' of the input by triggering the 'onchange' event. If it did, that would've probably resolve it. And in case of https://github.com/radzenhq/radzen-blazor/issues/1818 whatever action that would like to receive the result of ToFilterString() should ensure that all related numeric inputs on the page have 'committed' by invoking it manually. I tried something like this but I could not get it to work reliably: ```js <RadzenButton Text="Apply" Click="RadzenDataFilter" onmousedown=" var inputs = document.querySelectorAll('.rz-numeric-input'); inputs.forEach(function(input) { input.focus(); console.log('Focused: ' + input.className + ', Value: ' + input.value); // value is always as expected var changeEvent = new Event('change', { bubbles: true }); input.dispatchEvent(changeEvent); }); " /> ```

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/radzen-blazor#1508