Hi Mallika,

I added your Vote for both this request, and for this one - whichever gets implemented first would let you have the desired behavior. You can also click the Vote button yourself to raise the priority of items that are of interest to you - we do take the public interest into account when planning our next iterations, and the votes count is one of the most direct metrics. To know when either of them is implemented, click the Follow button on their pages - you will receive an email with status updates as they happen.

This thread here is not the right place for discussing such functionality, and at the moment there is no solution for implementing such a feature, neither through JS, nor through C#.

Regards,
Marin Bratanov
Progress Telerik

Alberto, please open a support ticket and send me a sample that reproduces this locally and a video of the problem. Also, keep in mind that the WASM flavor of Blazor has general performance issue (that is, it is considerably slower than the server-side flavor).

--Marin

Hi Alberto,

On my end, I can see how slowly the WS messages travel, which indicates a large latency. In such a case, such a problem is expected and it's not something we can fix. The WASM flavot is what I can recommend for this.

Regards,
Marin Bratanov
Progress Telerik

Hi Alberto,

We just noticed that, by default in Azure, WebSockets are disabled, and this is detrimental to the SignalR performance and causes lag. This is when I had been able to reproduce an issue. We just enabled them explicitly and I was not able to observe a problem anymore (you can see how to do that at the very end of this post). I have updated the docs article with this information. Could you try enabling web sockets to see if this will help? You can also try deploying to a cluster closer to the user base.

I am also attaching here two videos - one before web sockets were enabled that shows how much lag there is compared to a local run, and one after web sockets are enabled. My PC is also pretty slow and even so there was no issue for me. I must note that if the network distance is too great (e.g., a user in Europe accessing a server on the West Coast), even web sockets may have a lag that can cause a problem.

On why Syncfusion's menu does not exhibit this - to the best of my knowledge its a wrapper over a JS widget, which means that all its markup and code is rendered in the browser and shown with JS. On the other hand, our components are native, so the server generates the markup for the items in the dropdown, so a round-trip is required. We do animations on the client with JS for performance reasons already.

Regards,
Marin Bratanov
Progress Telerik

Hello Alberto,

We tested this by deploying to Azure as well, and it looks like the latency is simply too large for a server-side blazor app to work as expected. I documented this issue in the Deployment Troubleshooting article (commit diff). At this point, I do not believe there is anything more we could do about this case, we can't work around the laws of physics that add the network latency.

Regards,
Marin Bratanov
Progress Telerik

Hello Alberto,

We did not improve a specific case for a number of items. We reduced the events that go to the server. The more items there are, the larger the payload and it is likely that the diffs will be bigger, and this can cause slowdowns and the same type of asynchronous arrival of data that causes the problem here (which has the same root cause as the menu issue, the linked issues have better explanations on what happens).

The maximum speed of the LAN or Internet connection will not affect the latency - for example, you may still be able to run a speedtest to 100Mbps, all the while having latency too large to run a server blazor app.

Please open the web sockets tab of the Chrome dev tools and see whether you can see delay in the speed with which messages appear when requesting from the cloud and when hosting locally. You can also try a ping  command to see the latency you have to the server, but that may be lower than the actual delay for a SignalR request as they go through different code on the server.

I also uploaded the sample I previously attached to our staging server which has a higher latency (in my case it is several countries away) and it seems to work fine for me. I can clearly see some of the lag affecting the shown item when I move the mouse really quickly, but things still work fine for me. I am attaching a video of this so you can see what I mean. The latency a ping returns for me for this server varies between 60 and 120ms.

Also, do you have a site live I can observe this on?

Regards,
Marin Bratanov
Progress Telerik

What kind of latency are we talking about in the problematic case? I am asking because latency is a general problem for server-side Blazor and there are limits to what we could do - ultimately the events and expansion need to go to the server and it has to create the DOM diff. So for situations where large latency exists between a server and a client, a WASM app is likely to work much better.

Regards,
Marin Bratanov
Progress Telerik

Hi Alberto,

This seems to work fine for me. I am using 2.4.0 and .NET Core 3.1 Preview 3. Are using the same versions as well? I am also attaching here a sample and a video of the behavior I get from it so you can see if I am missing something. If you continue to experience this after upgrading to the latest version and comparing against this sample, I suggest you open a support ticket and show me how to reproduce it so we can investigate.

Regards,
Marin Bratanov
Progress Telerik

Hi Alberto,

While a feature where items open only on click would be a solution for this, it is also subject to general prioritization rules. At this stage, new components like a scheduler and a combo/autocomplete are higher on the list than a click to open feature in the menu.

As for the suitability of server-side Blazor - while MS do not state this explicitly (they could not afford to do that), this is the general consensus in the dev community, and the behavior and specifics of the server flavor point that way - the fact that every DOM update must go up to the server, then back down to the browser means that large latency will be problematic and therefore intranet is a better target environment for server blazor. Adding to that the scalability issues, a public facing server-blazor app is open to a relatively easy DoS attack.

Regards,
Marin Bratanov
Progress Telerik

Hello Alberto,

Those releases have had a different purpose - to add more charts, and to provide compatibility with new framework releases.

The fix of this issue requires a complete overhaul of the event handling system, which is not a trivial task, and requires some time.

It is also important to note that this issue manifests only for a server-side Blazor app when accessed over a large-latency connection (like our demos - being available to the general public over the Internet). This is, however, not the intended purpose of the server-side Blazor model - it is designed for Intranet use where latency is low, and the number of users is limited.
Ideally, our demos would use the client-side (WASM) flavor and this issue will be gone, but this is impossible at this point because the client-side flavor is still not production-ready.

In the intended purpose of server-side Blazor scenario, however, this issue is far less likely to manifest, if it happens at all.

With all that said, my best advice is to click the Follow button on this portal page, and you will get email notifications for status updates on this task. Once we know it has been handled, we will also add the release number to the page.

Regards,
Marin Bratanov
Progress Telerik

Hi,

I am reopening this for further investigation. It does not seem to manifest locally, but it does happen on our live demos, and the most likely problem is that there is a large latency to a server in the cloud (while server-side blazor is more suited to local environments).

Regards,
Marin Bratanov
Progress Telerik