Closed simasch closed 2 years ago
Hmm sounds like #34 . However, Karibu-Testing contains a test for that and it passes for Vaadin 23.0.0:
test("confirm") {
var confirmCalled = false
ConfirmDialog("Foo", "Bar", "Yes") { confirmCalled = true }.open()
_get<ConfirmDialog>()._fireConfirm()
expect(true) { confirmCalled }
_expectNone<ConfirmDialog>() // make sure the ConfirmDialog is closed: https://github.com/mvysny/karibu-testing/issues/34
}
I noticed something strange in your dump: the ConfirmDialog is nested within CategoryDialog. Usually dialogs should be placed as direct children straight under UI.
Do you have any special code, which would nest ConfirmDialog into CategoryDialog? If not, could it be that CategoryDialog is modal, causing any nested dialogs to be added as a children of ConfirmDialog rather than the UI (something akin the server-side modality curtain)? If that's true, then that's most probably the origin of the issue - Karibu-Testing only auto-cleans up dialogs nested directly under the UI...
I noticed something strange in your dump: the ConfirmDialog is nested within CategoryDialog. Usually dialogs should be placed as direct children straight under UI.
Yes that's very strange and I don't understand why this worked until beta3 and with newer versions this is broken.
I think that a server-side "modality curtain" has been developed in beta4+, which directly affects dialogs. Perhaps this kind of dialog nesting is an after effect. Let me investigate.
It was the case as I suspected. Not only for ConfirmDialog, but for the regular Dialog as well. Starting from Vaadin 23.0.0.beta4, when a modal dialog is opened while another modal dialog is active, the second dialog is nested inside of the first one, with respect to the server-side component hierarchy. I've changed Karibu-Testing to do a full sweep of all components attached to the current UI, to find and close such dialogs.
The fix will be present in Karibu-Testing 1.3.12
Well, it happens that if this first dialog is closed but have nested dialogs that still remain opened, this fella <cleanupDialogs()> ends up removing the first dialog along all nested dialogs within it, even if those were still opened.
I'd came out with this code to "recover" those still opened nested dialogs previous to the cleanupDialogs() call. It works well to my purposes, I share here in case someone finds it useful:
List<Dialog> dialogs = DialogUtilsKt.getAllDialogs();
if (dialogs != null) {
List<Dialog> nestedDialogs = new ArrayList<>();
dialogs.forEach(dialog -> DepthFirstTreeIteratorKt.walk(dialog).forEach(posibleNestedDialog -> {
if (posibleNestedDialog != dialog &&
posibleNestedDialog instanceof Dialog &&
((Dialog) posibleNestedDialog).isOpened()) {
nestedDialogs.add((Dialog) posibleNestedDialog);
}
}));
dialogs.addAll(nestedDialogs);
}
return dialogs.stream().filter(Dialog::isOpened).collect(Collectors.toList());
I have a test that worked with beta3 but now with 23.0.0 it fails
On the last line now I get
So this looks like the dialog is not closed with _fireConfirm()