Unplanned
Last Updated: 12 Jun 2024 06:20 by ADMIN
Jesper
Created on: 04 Jun 2024 13:09
Category: UI for Blazor
Type: Bug Report
4
telerikdropdownlist doesn't work when opened too fast
I am using MS Playwright to create End2End tests. It worked fine when we used MudBlazor, but after we migrated to telerik I have run into a problem with the TelerikDropDownList.

It stops working if you open it too fast. It goes into a state where no matter what you do (Rebind/changing data bound values etc.), it will not open and show items.

It can be reproduced easily by calling .Open() in OnInitializedAsync()

I have reproduced it without MS Playwright in REPL, so you can easily debug it.

https://blazorrepl.telerik.com/QIOUYoPc57iQKy6702

If you uncomment the await Task.Delay(3000); the code will work.

Expected behavior:
It is ok that Open() does nothing while the control is initializing. It is not ok that just because you called Open() once, then you are forever stuck without being able to open it later, no matter how long you wait or what you do with the items.

I do not want to insert random Delays in my code either as I expect the TelerikDropDownList to not malfunction just because I open it too early.

I hope you can prioritize this as right now the DropDownList is not usable for us.
4 comments
ADMIN
Dimo
Posted on: 12 Jun 2024 06:20

Hello Jesper,

Thanks for the detailed follow-up and additional information. We will use it when fixing the issue.

Regards,
Dimo
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Telerik family, check out our getting started resources!
Jesper
Posted on: 12 Jun 2024 03:44
Thanks for answering Dimo.

I think you misunderstood the purpose of the code in https://blazorrepl.telerik.com/QIOUYoPc57iQKy6702

I did not make it to show how we create E2E tests. I only made it to give you a very simple way of reproducing the error in the TelerikDropDownList.

In our real tests we do not test the TelerikDropDownList, as we expect You to have done that. We use them to select a value, which is written to a ViewModel, which is then sent to our API.

We use MS-Playwright to first open the DropDownList, then select one of the items in it.
We have created code that solves the waiting problem, since how long you should wait depends on the environment you run the code on and how much load is on the environment when the test is run.

If you just insert fixed time delays you run into the problem of how big should the delay be to ensure it will always be big enough. You can wait 30 seconds after each click and then it would probably work, but we have 100s of tests and then each of them would take hours to complete, so that is not a good idea.

We want to wait precisely long enough that it is ok to use the components and not longer than that. So what we do is that we have created an AsyncAwaiter method, that waits until the component is rendered, visible and stable, then it tries clicking on it and checks if the menu is opened. If the menu is opened it looks for the item we want to click on, if it can find it, it clicks on it. If either the menu does not open or the item is not found we wait a little while and then we check again. We then have a small timeout, after which we click on the DropDownList again and repeat this until we either succeed selecting the element or we run into a big timeout currently set to 30 secs in which case we fail the test.

This approach worked with MudBlazor and when we changed to use the TelerikDropDownList and (changed nothing else), then we end up in a case, where if we click on the TelerikDropDownList too soon, then no matter how many times we click later or how long we wait then it will not open and show items.

This led me to believe, that there is a race condition in the TelerikDropDownList.

You write that the issue will disappear if I don't call .Close() right after .Open(). That is not entirely correct. In the code example I gave you it is correct, but the latent race condition is still there. 
It will also manifest it self in some cases when all you do is call .Open() and it will also happen just if you click on the item with the mouse, given that the system is slow enough and you click fast enough, as happens in our case with lots of components and code running.

I have recreated another case for you, again using very simple code where this can happen. Unfortunately it only happens during certain conditions, so the error doesn't happen in general. I was lucky to find a situation where it happened and have made a video with it.

This is the code: https://blazorrepl.telerik.com/cyEAbcaR30yXHhtT05 IMPORTANT! This code works fine most of the time, but not always. For me to trigger the error I had to open the browser console when there was a lot of stuff in it, in order to create the race condition.

I will try and attach the video as well.
ADMIN
Dimo
Posted on: 11 Jun 2024 08:17

Hello Jesper,

I confirm that the DropDownList should not allow the app to throw it into an invalid or frozen state. In other words, this is a valid bug report. In the meantime, here are a few comments.

  • e2e tests normally mimic user behavior. Our own e2e tests use delays and waits too especially in scenarios, which involve interaction, animations and component state changes.
  • The problem in this case is caused by the immediate close. If you remove the .Close() call or insert a delay between .Open() and .Close(), the issue will disappear.
  • What brings the need to test opening and closing of our DropDownList? I understand that you may want to verify our components are working, but we already have tests for all operations, such as opening, closing, data binding, item selection, etc.

Regards,
Dimo
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Telerik family, check out our getting started resources!
Jesper
Posted on: 04 Jun 2024 13:17
It is not always enough to use the delay of 3000.

If this happens you can just comment the .Open() and .Close() out, to see that it will indeed show the items if you wait long enough before you click manually.