File menu remains open while Open dialog is visible about brackets

[njx]

Hmmm. Seems like in general we should try to figure out a solution that lets the browser render independently of native modal UI. I'm a little surprised that it doesn't.

[njx]

Assigning this to Glenn since it's mostly a native interaction issue.

[peterflynn]

Fwiw, I noticed the same thing happens with confirmation dialogs too: if you have an unsaved file open and then do File > Open, and choose Don't Save in the confirmation prompt, the confirmation prompt remains open/visible underneath the browse dialog that pops up afterward.

[njx]

Reassigning to Peter to verify this bug is fixed and close it.

[peterflynn]

Seems like another option, long-term, would be to run the dialogs on a different thread from the browser rendering engine. Since our code has to be written to cope with modeless dialogs anyway (for the in-browser case), this shouldn't be a problem... the only issue might be if Chromium and the OS dialogs both insist on the same specific thread.

[gruehle]

CEF, as currently written, must have all client UI on the same thread as browser UI. There is an enhancement request to make CEF support multiple UI threads, but there is no guarantee it will be done.

[peterflynn]

Looks good here.

To NJ's point, as soon as we start confirming unsaved changes when we switch projects (landing tomorrow?) we'll be back in a state where a native browse dialog appears right after an HTML dialog is dismissed. That said, having the background-grayout layer still be visible at that point doesn't actually feel so bad to me.