[Bug]: Multiple non-modal dialogs closing issue

[Filip00007]

What happened?

While poping-up multiple non-modal dialog windows and closing them in different order than it was opened causes user to click two times on X icon (or close button) and also new dialog reappears...

Expected Behavior

Closing multiple dialog windows should not be dependent on order of theirs opening and aslo should not cause automatic reopening of a new dialog...

Screenshots

https://github.com/fgilde/MudBlazor.Extensions/assets/134936703/9f874006-a246-46c7-9dd7-2971f2d5fcf4

What application type are you referring to?

ServerRendered

Custom Application Type

No response

MudBlazor.Extension Version

1.7.66

MudBlazor Version

6.9.0

What browser are you using?

Chrome

Sample Solution

No response

Pull Request

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[fgilde]

will have a look at this.

[fgilde]

I fixed the direct interaction with the buttons on first click. But the other problem I cant solve currently without a good idea and its still an open issues. Problem is when closing in the same reverse order everything works fine. But with other order MudBlazor forces a statechange and whole ui regenerates what causes new reference elements for the dialogs and the dialogs itself. To solve this I reinit the dialog options on js side currently and this resets the last sate. Maybe i need to find a better way, but currently i didnt have an idea.

Last changes are deployed in 1.7.67

[SpikeThatMike]

I also have an issue similar to this. When opening two dialogs in non-modal mode & resizable, lets say dialog 1 and dialog 2.

if I open dialog 1 then open up dialog 2, I can move them both. If I then close dialog 2 (the most recent opened one) I can still move dialog 1 around & resize it. However if I did it the other way around so I close dialog 1 first, dialog 2 doesn't let you move or resize it

[Alexr03]

Am also running into this problem, would love for this to be looked at for a fix again 🙏🏼

[M0RG4N01]

I face the same issue and would really like to use non-modal because its great to have multiple dialogs open. If I do as the creator mentioned and close dialogs in the perfect reverse order its great; otherwise, it'll bug out.

[fgilde]

I will check again what I can do to solve it. Maybe need to create a Pull Request in MudBlazor because there is the event handling that forces this issue

[Alexr03]

I will check again what I can do to solve it. Maybe need to create a Pull Request in MudBlazor because there is the event handling that forces this issue

Thanks for taking another look at this! :D If you need me to test any changes let me know.

[lafsar]

I am running into this same issue. We are unable to move forward with this until this is solved. What are the changes that need to be made to MudBlazor to help this?

[fgilde]

I can't remember at this moment. And I need to fully re invest on this with the newest Mudblazor 8.0.0. I will definitely do that, but It is very complicated and was very frustrating for me as well and the main issue is currently dedicated time for doing that.

But I will investigate to this again I promise. Sorry sorry for long delay I know Feature is very long in Beta at this moment.

[lafsar]

I found a temporary hack / workaround to get past this issue:

Subscribe to the closing event on IDialogEventService. Intercept the cancel in the handler, manually remove the dialog using MudDialogProvider internals:

private async Task CLoseDialogCorrectly(DialogClosingEvent arg)
{
    var guid = GetDialogGuid(arg.DialogId);
    var dialogRef = GetDialogReference(guid);
    bool hasDismissed = dialogRef.Dismiss(DialogResult.Cancel());
    if (hasDismissed)
    {
	//MudDialogProvider
        FieldInfo dialogs = DialogState.Value?.DialogProvider?.GetType().GetField("_dialogs", BindingFlags.NonPublic | BindingFlags.Instance);
        MethodInfo removeMethod = dialogs.FieldType.GetMethod("Remove", BindingFlags.Public | BindingFlags.Instance);
        removeMethod.Invoke(dialogs.GetValue(DialogState.Value?.DialogProvider), new object[] { dialogRef });
        arg.Cancel = false;
        // below line is the fix 
        dialogRef.CloseAnimated();
    }
}

private IDialogReference GetDialogReference(Guid guid) {
    MethodInfo getDialog = DialogState.Value?.DialogProvider?.GetType().GetMethod("GetDialogReference",
    BindingFlags.NonPublic | BindingFlags.Instance);
    IDialogReference? dialogRef = (IDialogReference)getDialog.Invoke(DialogState.Value.DialogProvider, new object[] { guid });
    return dialogRef;
}

private Guid GetDialogGuid(string id) {
    return Guid.Parse(id.Remove(0, 1));
}

[fgilde]

This only helps for using the X close button and not for Submit or Cancel

[fgilde]

The real problem ist the StateHasChanged from the MudDialogProvider. That means also in your workaround if you afterwards open a new dialogs you will still have the problem in general. Thats the reason why I reInitialized all dialogs on the js side. but this also causes other side effects.

[fgilde]

If you want to playaround withit, I created a branch 42-no-modal

You can check it out and have a look in the MudExDialogService.cs and the dialogNoModalHandler.js Maybe somebody finds a good idea for me here. In this branch I also simplified the js to prevent new errors with another test solution.

You will see now If you are closing in the wrong order and the state changed kicks in the dialogs are in visible because of the re applied mud-ex-dialog-initial class and also the overflay is clickable again and you cant click anywhere.