How can this still be unplanned? It seems like a simple thing to fix, that has a lot of impact for users. It is a pretty important component.

I need to take a decission soon on a new web project wether to use Telerik or not. If this is something you will not fix then my recommendation will be to not use Telerik.

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.

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.