Bug introduced in 11.0 or earlier and persisting through 11.2

[...] I was able to reproduce the issue, and consequently, I filed a report with our development team [...]


I find this behavior unexpected and I would like to ask whether it is only me who thinks it is a bug.

The case

It seems that MessageDialog and CreateDialog windows are interfering with kernel blocking dialogs (e.g. DialogInput) on WindowClose event of one of formers. E.g. please create those 3 dialogs:

CreateWindow @ DialogNotebook["regular dialog (CreateDocument), close it first"]

CreateDialog["regular dialog, close it as a second", 
 WindowMargins -> {{0, Automatic}, {Automatic, 0}}]

DialogInput["kernel blocking dialog waiting for input", 
 WindowMargins -> {{0, Automatic}, {Automatic, 200}}]

After that the kernel is waiting for DialogInput response. But before that let's close other notebooks.

The manually created one (CreateWindow) does nothing but exiting CreateDialog makes the Kernel to think that it was the DialogInput one - $Failed is returned.

Which is unexpected and makes MessageDialog/CreateDialog too unstable. Every kernel blocking dialog can also be a FrontEnd blocking one (Modal -> True) but it won't save us completely as there is another bug related to dialogs: Notebooks created after prompting a Modal dialog


I believe it is caused by:

"WindowClose" :> (FE`Evaluate[FEPrivate`FindAndClickCancelButton[]];

which is inserted to all higher level dialog functions like MessageDialog.


Already reported, but what do you think, is it expected, is there a good reason behind that?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.