Double clicking "Ok" button on Confirm(string)-generated dialog produces multple DialogService responses

Radzen.Blazor Components
1

I am writing a data importer that tries to recognize a user and, upon recognition, suggests that the user import their legacy data. All dialogs are run using an injected instance of DialogService.

When recognition is successful, call
bool importData = await DialogService.Confirm("Would you like to import your data?") ?? false;

If the user clicks "Ok", I immediately send a confirmation email, then pop up a new window to wait for the user's code from their email.
Dictionary<string, object> parameters = new Dictionary<string, object>() { { "Email", email } };
DialogOptions options = new DialogOptions()
{
CssClass = "myCustomClass"
};
bool validated = await DialogService.OpenAsync("Email Confirmation", parameters, options);

The problem is that, if the user double-clicks the "Ok" button in the Confirm window, it appears that an additional response is cached and, when OpenAsync is called, it immediately (at least from a human perspective) returns 'true' even though the user hasn't entered their code, or even seen the dialog appear at all.

It may also be worth noting that ConfirmEmail's life cycle methods ARE being run (I can set a break point in OnInitlialized). But the code that I have within ConfirmEmail.razor.cs to perform the Close operation does not get hit. It's being closed by something external to my control, AND it's returning a boolean 'true' value.

Attempting to create a new instance of DialogService results in the ConfirmEmail not being displayed at all. It appears to not have access to the DOM, or something, because it seemingly just hangs. No exception is thrown, or anything. Nothing appears and my code stops. So it looks like it's awaiting the call to OpenAsync indefinitely.

How might I ensure that my second dialog is not prematurely closed?

Edit: It occurred to me that I hadn't updated versions in bit, and I was running 4.15.12. However, even after updating to 4.18.1, the issue remains.

2

Hi @lassanter,

Indeed double clicking will cause multiple click events of the button to occur. We are not doing anything to prevent that as I think this is the default button behavior.

3

Certainly a given button should fire its event handler every time it is clicked. The issue is that it's polluting the behavior of other dialogs. Why is the Click event from the button on the Confirm dialog causing the next displayed dialog to close?

4

I am not sure. Probably the next dialog shows immediately and consumes the second click. Only debugging can tell for sure.

1 Like
5

I will admit that I am fairly new to dealing with open source code maintainers. Is it common for maintainers to be so dismissive of bad functionality in their code? Or are you under the impression that everything I am discussing is occurring within my own code?

Your Confirm dialog, displayed via code internal to DialogService, is causing an issue with further uses of that service. And your response is to tell me to "debug" it. Thus necessitating that I create a whole new project around this issue, pull in your repository, and debug your code.

I don't have a problem with this, conceptually, as that IS what open source is all about. But it seems quite brazen to simply dismiss issues so casually. Am I missing a point of open source etiquette that makes your response justified?

6

Hi @lassanter,

We will need a reproduction of this issue - some sample code that we can run without external dependencies. Until we have a reproduction we can't tell more.

By the way being aggressive towards open source maintainers and demanding solutions is usually frowned upon. I suggest reconsidering your approach to communicating with us.

7

It was not my intent to demand. If I came off that way, I sincerely apologize. I was simply shocked at the response, as it seemed dismissive and uncaring. So shocked that I genuinely believed that I was missing something in open source etiquette that made such a response appropriate. But if your intent was to not be dismissive, and it was simply a matter of interpretation on my part, then I am happy to move on and work toward a solution to the issue.

I will see if I can reproduce the issue in a standalone project. Do you prefer a public repository, or an attachment?

8

Our forum would probably disallow attachments above certain size. I would recommend opening a github issue in our repository and either uploading the project there or linking a repository of your own.

1 Like