Progress® Telerik® UI for Blazor Feedback Portal
Back to Feed
Request a Feature Report a Bug
Declined
Last Updated: 04 Sep 2024 14:33 by Rob
Michal
Created on: 28 May 2024 09:58
Category: UI for Blazor
Type: Bug Report
3
Dialogs and Loading indicator z-index broken v6.0

Hi,

starting with version 6.0, dialogs used together with loading indicator are at wrong z-index order.

- None of hotfixes with "delay" helped.

- users are stucked and cant confirm anything

How to replicate

Click on "Show Confirm with loading indicator". Loading animation should be at BACK of confirm dialog(as at older versions, prior 6.0)

https://blazorrepl.telerik.com/GeOfQMkt56AMkdof43

 

7 comments
Rob
Posted on: 04 Sep 2024 14:33

Ok, I was annoyed by this change - it broke a few places of my app where similar to Michal I alert while IsBusy=true.  I also believe the change could have been communicated better.

However, my counter-argument demo was unexpectedly working (Click the refresh button in the "Currently" tile).  I realized my postition:relative loadercontainer could have its own stacking context by setting its z-index.

Thanks, I learned something today!

Johannes
Posted on: 18 Jul 2024 06:31

Just adding some more customer demand.

I can understand that the LoadingContainer is used to stop interaction with the page, but I generally show Dialogs when I want a user to interact with it. When I don't want a user to interact with a dialog, I take it away.

A css fix works, but in a few releases time when there is a new class name or extra parent added in for something, I am going to have to follow it all through to work out why my dialogs are unable to be interacted with again.

ADMIN
Dimo
Posted on: 05 Jun 2024 11:50

Hi Michal,

Thanks for sharing your point of view and suggestions. I must admit that they make sense, but the end result will be a more complex CSS theme, which supports a more complex and rare scenario. We can consider this approach if there is enough customer demand.

In the meantime, our primary suggestion is not to use the LoaderContainer and predefined Dialogs at the same time. If you require this, then it is possible to increase the z-index of predefined Dialogs like this:

<style>
    .k-dialog-wrapper:has(.k-alert) {
        z-index: 21000 !important;
    }
</style>

<TelerikLoaderContainer Visible="@LoaderContainerVisible" />

<TelerikButton OnClick="@( () => DialogVisible = true )">Show Dialog</TelerikButton>

<TelerikDialog @bind-Visible="@DialogVisible"
               Width="600px"
               ShowCloseButton="true"
               CloseOnOverlayClick="true"
               ButtonsLayout="@DialogButtonsLayout.End">
    <DialogTitle>
        Dialog Title
    </DialogTitle>
    <DialogContent>
        <TelerikButton OnClick="@ShowPredefinedDialog">Show Predefined Dialog</TelerikButton>
    </DialogContent>
    <DialogButtons>
        <TelerikButton OnClick="@( () => DialogVisible = false )">Close</TelerikButton>
    </DialogButtons>
</TelerikDialog>

@code {
    [CascadingParameter]
    public DialogFactory? Dialogs { get; set; }

    private bool LoaderContainerVisible { get; set; }

    private bool DialogVisible { get; set; }

    private async Task ShowPredefinedDialog()
    {
        LoaderContainerVisible = true;

        await Task.Delay(600);

        if (Dialogs != null)
        {
            await Dialogs.AlertAsync("Predefined Dialog over the LoaderContainer");
        }

        await Task.Delay(300);

        LoaderContainerVisible = false;
    }
}

 

Regards,
Dimo
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Telerik family, check out our getting started resources!
Michal
Posted on: 05 Jun 2024 05:45

Hi Dimo,

 after review of request(root of the zindex change to higher value) and actual result consider this:

 

DO NOT mix windows/modals/popovers/dialogs with PREDEFINED dialogs: 

alert/confirm/prompt
https://docs.telerik.com/blazor-ui/components/dialog/predefined

thoose are for different purpose with different behaviour.
As example, get inspiration from OS and zindex orders in manner of UX.
->1 desktop->2 app->3 loading->4 prompt->4 loading->5 another window "always on top"->6 loading->7 confirm retry/continue->7loading..->8anotehor window....->9lock screen->10 prompt->99999999999screen saver(over).

If you BLOCK ui state when ASKING/CONFIRMING user for something, you are stucked = avoid this.

So expected z-index order is:

- regular ui elements->predefined dialogs ->blazor disconnect modal->blazor error

Suggested solution:

- different class and different zindex for window/dialog/modal/popovers and PREDEFINED dialogs
- or anything to get prompts behave as rest of the world(do not reinvent the wheel) :)

Its not about "hotfix"(which is ok for now), just to make components better in long run term.

What do You think?

ADMIN
Dimo
Posted on: 03 Jun 2024 14:34

Hi Michal,

The z-index change is now documented on the Rendering Changes page for version 6.0. Normally, we don't document changes in the CSS code, because we consider it a "private API". However, I agree this case is more special.

If you are interested, you can keep an eye on the Themes release notes, for example:

https://github.com/telerik/kendo-themes/releases/tag/v8.0.0

Bug Fixes

Regards,
Dimo
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Telerik family, check out our getting started resources!
Michal
Posted on: 03 Jun 2024 10:47

Hi Dimo,

 thanks for the "magic game-saver" constant.

- It would be nice, to put it in documentation - breaking changes v4,5 going to->v6. Including this suggetsion with z-index value. Its nice, and it not so painfull. Should be working in nested modals also.

 

When using UX principles:
- click button/action,  block the UI with loader, do "long/undefined" work, ask user with DialogConfirm or any aditional questions, continue with still blocked UI behind, done, unblock.

v6:
        click...
if (IsBusy) return;IsBusy=true;
some query/long task...
IsBusy = false;//!!
if (!await Dialogs.ConfirmAsync(xinfo)) return;
IsBusy = true;//!!
StateHasChanged();//!!
...continue query/long task
finally:
IsBusy = false;
StateHasChanged();//!!
meh :)

v5 - was:
if (IsBusy) return;IsBusy=true;
some query/long task...
if (!await Dialogs.ConfirmAsync(xinfo)) return;
...continue query/long task
finally:
IsBusy = false;

 

ADMIN
Dimo
Posted on: 03 Jun 2024 10:08

Hello Michal,

We increased the z-index of the LoaderContainer for version 6.0, so that it can show over popup Windows.

The purpose of TelerikLoaderContainer (and loading indicators in general) is to signify long running tasks and prevent user interaction with the page. On the other hand, the Telerik Dialog component has its own overlay. When you show the LoaderContainer before showing the Dialog, this renders two modal overlays at the same time, which is not necessary.

My suggestion is to set IsBusy to true after the user confirms their choice in the modal Dialog and before the actual long running task starts.

If there is a special reason to show the LoaderContainer earlier, then you can reduce its z-index style value with CSS:

div.k-loader-container {
    z-index: 9999; /* anything below 10,000 */
}

Regards,
Dimo
Progress Telerik

Stay tuned by visiting our public roadmap and feedback portal pages! Or perhaps, if you are new to our Telerik family, check out our getting started resources!
Create an account Log In
View
Type
Status
Category