Progress® Telerik® UI for Blazor Feedback Portal
Back to Feed
Request a Feature Report a Bug
Unplanned
Last Updated: 06 Jun 2025 13:58 by Joe
Joe
Created on: 23 May 2025 15:52
Category: UI for Blazor
Type: Bug Report
6
date picker invalid
There is a date picker bug where if you change the value to something invalid (ex: backspace the date or a portion of it), it will still be bound to the previous date value selected. If you click the picker and select the same date again, it will not register it as a date change and will not fire the value changed event. This causes the field to still show as invalid. To the end-user, it looks as if there is a problem and is telling them it is invalid. I had a customer notice this and they kept trying to reselect the date but nothing would happen. 

They eventually typed it manually to fix, which is one way that I agree can be used to resolve. You can also select the wrong date, followed by the right date to get around, but that is a horrible workaround. 

What I believe the experience should be is that when selecting the value in the date picker, regardless of what it thinks is in the field, it should fire the change event and update the text of the field to the date selected (and clear the validation message). That is what I'd like to see as a future change. Note that this happens on ValueChanged, but not OnChanged. OnChanged fires too late though, and doesn't work for most workflows.

We put in a hack solution in some operator UIs where it is very important to not have this happen, but it is a pain to do this for every picker, so most in the system are unhandled. 

The solution was to have OnOpen and OnBlur both manually trigger ValueChanged (which ends up sending default - 1/1/1901) using a reference for the control. This helps us differentiate if it is these events vs an actual date change. When it is OnOpen/OnBlur, we then reupdate the value in the reference and refresh. Note that you end up having to do this twice to "trick" the telerik logic. So we change to default, refresh, and then change to the correct (or last good value - what is already bound) and refresh. Basically now when they leave the field or click the picker, if there is an invalid value and message, it clears and gets replaced with the last good date. If there is a valid date, it does nothing from the user perspective.  
7 comments
Joe
Posted on: 06 Jun 2025 13:58
Sounds good - I think that is likely the quickest solution or path of least resistance for you. I think that should work fine. Thanks again!
ADMIN
Dimo
Posted on: 06 Jun 2025 13:49

Thanks for the insights, Joe, much appreciated!

In the meantime, we decided to go with option #1 (auto revert to the existing component value on blur), because this will lead to consistent UI and application state.

Joe
Posted on: 06 Jun 2025 13:19
Hello Dimo,

I appreciate the team revisiting and agreeing to make a change. Both options you stated would be sufficient in my opinion. #2 might make for a slightly more intuitive user experience (as nothing would be automatically/unexpectedly happening), however, I think both would yield a positive user experience that would be understood. #1 aligns with our workaround and seems to be working fine for our customer. I just don't want to have to spend time writing workarounds for every date picker component (and right now I'm just doing so on key operator interfaces). 

As far as your customer question - We do have the datepicker component on many reports and UIs, but they are typically keeping the default values. The issue hadn't come up until we rolled out a new UI that is used by operators on a factory floor (whereas the others are used by system admins). The date is a required field and they will often change what is suggested to them. It only took one day of the UI going live before the issue was reported to me. At that time I tried to replicate and let them know what to do for a workaround. The next day we released a hotfix with the solution mentioned, so there wasn't a large enough window to let you know how often it was happening. I'm assuming it was set to an invalid state by accident. Keep in mind not all users are tech-savvy and it was a new process rolled out. This UI in particular is very important to be error-proof.

Interesting on nullable vs not nullable. We did discuss possibly making the model not nullable, while still requiring in the end (as it's a required field), but it was going to require a bunch of rewriting and extra handling for many of the rules in the UI (as there are rules that relate to the selected date).

Thanks again,
- Joe
ADMIN
Dimo
Posted on: 06 Jun 2025 10:48

Hello Joe,

Thanks for the test page and thoughts.

We revisited this case and agree there may be a need to change the default component behavior. At first glance, there seem to be two options:

  • The DateInput should automatically refresh itself and display the current valid value on blur.
  • Once the DateInput state becomes invalid, the component should allow the user to reselect the desired date from the popup Calendar even if it's the same as the current one.

We are currently discussing this with our UX team and will update the thread afterwards. In the meantime, let us know if you have additional comments. For example, I am curious to know if the described original problem (accidental or deliberate textbox value invalidation) occurs regularly in your case and why.

On a side note, nullable values yield better user experience now, because the user is able to reselect the desired value from the Calendar popup with a single step: https://blazorrepl.telerik.com/wfOqEgvY30SPlbZe41

Regards,
Dimo
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.

Joe
Posted on: 30 May 2025 15:20
Apologies, for some reason my REPL link above is just loading a blank slate. I'm not sure what happened. Below is a new URL that is working at this time. 

https://blazorrepl.telerik.com/QpuzduPJ18geJ8GE00

Thanks!
Joe
Posted on: 30 May 2025 15:14

Hello - thanks for the response. Let’s take a step back and remove the technical portion and look at it from a user experience/perspective standpoint.

The date picker component has two independent abilities to enter a date. 1) Typing/changing it manually via keyboard and 2) selecting a date from a calendar picker/view.

Use Case: The user is seeing an “invalid date” message for whatever reason (maybe they cleared by accident or did something funky). Regardless, they are using the calendar/picker to select the date (method #2 above) to fix, which is their normal method. They keep selecting the correct date and nothing is happening. The date shown does not reflect their selection and they continue to see the same (unchanged) message. From their perspective, the control is not responding to their selection and is not working. Intuitively, no new information is being provided either. No matter how you break it down, this is a bug/issue as far as the user experience. Additionally, the OnChange event does not have this issue, so I believe it is not completely intentional.

The current workaround is to select the wrong date, exit, and then select the correct date, but I think you’ll agree that this is very backwards. Alternatively, you can manually type to fix the date. This is not their normal method, and the message does not say to manually type the date to resolve. Either way, one feature (calendar picker) should not depend on the other to work (I shouldn’t have to type to get the calendar picker to work again). Essentially the calendar picker is broken until you fix what is in the textbox through either workaround.

Below are a few suggested ways to resolve this issue, each of which I believe should be a small amount of effort on Telerik's end.

  1. (Recommended) Always respect the date the user selects in the calendar picker. These will all be valid dates after all. If the date is already bound, then just update the textbox and state/message to valid to match. If it is a new date, fire value changed and it will automatically handle.
  2. Always fire the value changed event upon selection. It then becomes a “value selected” event. Doesn’t matter. The behavior should still be such that the component respects the selection.
  3. If there is an invalid state, upon opening the picker, reinitialize the textbox and state/message to match the bound field in the picker.
    • You are showing it as the value in the picker but not in the textbox, so things are not aligned visually to the user. This realigns them.
    • Note: This is the hack workaround that we created, but ideally we don’t want to have to write something for this in every datepicker in our applications. Basically, OnOpen and OnBlur, we reinitialize this info.
    • Here is a REPL demonstrating this hack workaround: https://blazorrepl.telerik.com/GTazHavJ11Elm2uQ1


Thanks,
- Joe

ADMIN
Nadezhda Tacheva
Posted on: 30 May 2025 13:41

Hi Joe,

If I properly understand, the issue you are referring to is that ValueChanged does not fire in the following scenario:

  • The user deletes a portion of the DatePicker value, so it appears as invalid.
  • At this stage, the component value is still the old one, valid value.
  • The user then retypes the same value or selects it from the popup.
  • ValueChanged is not fired.

If my understanding is correct, I must confirm the described behavior is expected and it is not a bug. The value of the DatePicker can only be changed when a valid date is typed/selected from the popup. Otherwise, the component cannot parse it. Thus, if the user deletes a portion of the date, the input value is no longer a valid DateTime and the DatePicker value is not updated.

By design, the ValueChanged event fires upon change - a Calendar selection and during typing when the resulting input value is valid. As in the above-described scenario, there is no actual change in the DatePicker value, the component cannot fire the ValueChanged event.

Having the above in mind, I have marked the status of the item as "Won't fix" as the behavior is expected.

===

Last but not least, I'd like to cover the last part (underlined) of your following statement:

"There is a date picker bug where if you change the value to something invalid (ex: backspace the date or a portion of it), it will still be bound to the previous date value selected. If you click the picker and select the same date again, it will not register it as a date change and will not fire the value changed event. This causes the field to still show as invalid."

I must note that in this case, after the user selects the same date again, ValueChanged is not fired (expectedly as we confirmed above) but as this selection results in a valid value, the DatePicker is no longer marked as invalid.

This is the expected behavior: https://app.screencast.com/6SnibsW8OsoGj.

As you may notice, as soon as the user selects/types a valid date, the red border indicating the invalid state of the component disappears. If you are experiencing any different behavior in this regard, please open a dedicated ticket and share a runnable sample that demonstrates the problem, so we can revise it additionally.

Regards,
Nadezhda Tacheva
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.

Create an account Log In
View
Type
Status
Category