Hi,
I have a problem where the Dialog overlay remains after closing it and navigating to another view.
The Dialog is no longer visibile but the transparent overlay is still there and I cannot do anything on the view.
I’m using 24.9.3.
Sounds like a weird timing glitch.
I have proposed an API to configure Dialog to autoclose on navigate if you need that. Sometimes you want the Dialog to stay sometimes not.
is it a modal dialog? If yes… there was a recent refactor that might created an upsie…
Yes a modal dialog.
I have Dialog → Dialog → navigation to another view
I call close () before navigation
This works for me in 24.9.4 - both Dialogs are gone and the second view is rendered
add(new Button("Click me", e -> {
var firstDialog = new Dialog();
firstDialog.add(new Button("Open Second", x -> {
var secondDialog = new Dialog();
secondDialog.add(new Button("Close and navigate", y -> {
secondDialog.close();
firstDialog.close();
UI.getCurrent().navigate(SecondView.class);
}));
secondDialog.open();
}));
firstDialog.open();
}));
1 Like
That’s weird. I need to create a reproducible example
That’s super weird!
Important: close() is called in a class that extends Dialog.
When doing this:
close();
UI.getCurrent().navigate(GuestRegistrationSuccessView.class, registration.id().toString());
The transparent dialog overlay stays.
But when doing this:
UI.getCurrent().navigate(GuestRegistrationSuccessView.class, registration.id().toString());
close();
Everything works as expected.
@knoobie Can you reproduce that?
No luck on my side… this also works :/
add(new Button("Click me", e -> {
new MyDialog(null);
}));
static class MyDialog extends Dialog {
public MyDialog(@Nullable MyDialog other) {
super();
add(new Button("Click Me " + other, e -> {
if (null == other) {
new MyDialog(this);
} else {
other.close();
close();
UI.getCurrent().navigate(OtherView.class);
}
}));
open();
}
}
When inheriting, are you overriding any of the parent class methods?
No I don’t override any method . Just a simple dialog
I have observed similar behaviour.
I have an entity editor (dialog) which provides a “clone” functionality (same entity populated with current field values, but id set to null)
To visually differentiate the two editors and provide the user with a clear visual clue that he is cloning the entity, I decided to use dialog.addClassNames(LumoUtility.BackdropBlur.DEFAULT); on the cloning dialog.
The original dialog does not have this set.
UX is as follows:
To edit an existing entity (dialog 1 open)
Click “Clone” button in dialog
new dialog instance created
currentDialog.close()
newDialog.open()
Clicking cancel on the clone dialog (the one with the BackdropBlur)
Dialog closes, overlay remains
Interestingly, clicking on cancel in original dialog, produces no overlay issues.
- This is never observed on Chrome
- This is observed on Safari, though not always
In case it matters
OS: MacOS 26.1 (25B78)
Vaadin: 24.9.1
Safari: 26.1 (21622.2.11.11.9)
Chrome: 142.0.7444.60
That’s a really interesting observation, especially isolating it to Safari and the dialog with the BackdropBlur class! The fact that the original dialog closes clean but the clone (with the blur) leaves the overlay behind strongly suggests some kind of browser rendering quirk where the CSS effect is delaying or blocking the overlay cleanup on close. Good detailed repro steps.