ADMIN EDIT
You can use the code snippet below to test this behavior in your app. At the end of the post you will find two sample apps attached that use that same code - one is OK, the other exhibits the issue. The difference in them is the layout. The one that works OK has the old MS template from over a year ago where there is an <app> element above the root of the blazor components, and that element has display: flex. The problematic app has the newer template without such a parent element - the parent element is not the <body> and it does not have display:flex. You can add in the following rule to it to see it will fix the dialog overlay error (but it can damage the layout of the app).
sample rule to fix the issue in the problematic app
body {
display:flex;
}sample code to test the behavior
<TelerikWindow Modal="true" @bind-Visible="@isModalVisible">
<WindowTitle>
<strong>The Title</strong>
</WindowTitle>
<WindowContent>
I am modal so the page behind me is not available to the user.
<br />
<TelerikButton OnClick="@( _ => isSecondModalVisible = true )">Open the SECOND window</TelerikButton>
<TelerikButton OnClick="@ShowConfirmWithTitle">Show Confirm</TelerikButton>
</WindowContent>
<WindowActions>
<WindowAction Name="Minimize" />
<WindowAction Name="Maximize" />
<WindowAction Name="Close" />
</WindowActions>
</TelerikWindow>
<TelerikWindow Modal="true" @bind-Visible="@isSecondModalVisible">
<WindowTitle>
<strong>The SECOND</strong>
</WindowTitle>
<WindowContent>
Second modal!
</WindowContent>
<WindowActions>
<WindowAction Name="Minimize" />
<WindowAction Name="Maximize" />
<WindowAction Name="Close" />
</WindowActions>
</TelerikWindow>
<TelerikButton OnClick="@( _ => isModalVisible = true )">Open the window</TelerikButton>
@code{
[CascadingParameter]
public DialogFactory Dialogs { get; set; }
bool isModalVisible { get; set; }
bool isSecondModalVisible { get; set; }
async Task ShowConfirmWithTitle()
{
bool isConfirmed = await Dialogs.ConfirmAsync("Are you sure?", "Confirmation!");
Console.WriteLine($"The user is sure: {isConfirmed}.");
}
}
Hi Michal,
The proposed workaround is applicable for TelerikWindow component from which Predefined Dialogs are triggered. At the time of writing the admin edit the TelerikDialog component was not yet available, we only had the Predefined Dialogs.
Testing the TelerikWindow with this workaround seems to work as expected on my end. This is the result I am getting after I click the Delete button of the Grid inside a modal Window in order to open the built-in ConfirmDelete dialog:
Having this in mind, for the time being you can substitute the Dialog with a Window component in order to use this workaround until the issue is fixed.
If you want to keep your current configuration of a Dialog with a Grid inside it, you may add some custom CSS to reduce the z-index of the Dialog component and the k-overlay element. Set their z-index value to 10000, for example, to ensure they will be rendered behind the other dialog. This approach, however, could be tricky - I strongly recommend to use it only if you have one instance of a Dialog component on the page, scope the custom CSS to this page and use a custom class for the Dialog component modifications. Otherwise, things can get mixed up as the z-index of these elements is dynamically changed in some scenarios (e.g. when you have stacked dialogs) and you might end up with some undesired behavior.
The safer approach I would recommend at this stage is to use the Window component as suggested above. I hope you will find the above information useful. Please let us know if other questions are raised.
Regards,
Nadezhda Tacheva
Progress Telerik
Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.
