6 added 34 characters in body
source | link

Bug presists throughintroduced in 11.0 or earlier and persisting through 11.12

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

CASE:3805351


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

Investigation

I believe it is caused by:

"WindowClose" :> (FE`Evaluate[FEPrivate`FindAndClickCancelButton[]];
   DialogReturn[$Failed])

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

Question

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

Bug presists through 11.0.1

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

CASE:3805351


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

Investigation

I believe it is caused by:

"WindowClose" :> (FE`Evaluate[FEPrivate`FindAndClickCancelButton[]];
   DialogReturn[$Failed])

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

Question

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

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 [...]

CASE:3805351


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

Investigation

I believe it is caused by:

"WindowClose" :> (FE`Evaluate[FEPrivate`FindAndClickCancelButton[]];
   DialogReturn[$Failed])

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

Question

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

5 replaced http://mathematica.stackexchange.com/ with https://mathematica.stackexchange.com/
source | link

Bug presists through 11.0.1

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

CASE:3805351


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 dialogNotebooks created after prompting a Modal dialog

Investigation

I believe it is caused by:

"WindowClose" :> (FE`Evaluate[FEPrivate`FindAndClickCancelButton[]];
   DialogReturn[$Failed])

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

Question

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

Bug presists through 11.0.1

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

CASE:3805351


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

Investigation

I believe it is caused by:

"WindowClose" :> (FE`Evaluate[FEPrivate`FindAndClickCancelButton[]];
   DialogReturn[$Failed])

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

Question

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

Bug presists through 11.0.1

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

CASE:3805351


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

Investigation

I believe it is caused by:

"WindowClose" :> (FE`Evaluate[FEPrivate`FindAndClickCancelButton[]];
   DialogReturn[$Failed])

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

Question

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

4 added 184 characters in body; edited tags
source | link

Bug presists through 11.0.1

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

CASE:3805351


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

Investigation

I believe it is caused by:

"WindowClose" :> (FE`Evaluate[FEPrivate`FindAndClickCancelButton[]];
   DialogReturn[$Failed])

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

Question

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

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

Investigation

I believe it is caused by:

"WindowClose" :> (FE`Evaluate[FEPrivate`FindAndClickCancelButton[]];
   DialogReturn[$Failed])

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

Question

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

Bug presists through 11.0.1

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

CASE:3805351


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

Investigation

I believe it is caused by:

"WindowClose" :> (FE`Evaluate[FEPrivate`FindAndClickCancelButton[]];
   DialogReturn[$Failed])

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

Question

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

    Tweeted twitter.com/StackMma/status/811515531790577664
3 added 176 characters in body
source | link
2 edited body; edited title
source | link
1
source | link