Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message boxes hang on Windows #1698

Closed
branpk opened this issue Sep 7, 2020 · 12 comments
Closed

Message boxes hang on Windows #1698

branpk opened this issue Sep 7, 2020 · 12 comments

Comments

@branpk
Copy link

branpk commented Sep 7, 2020

Using a different library to open a message box after creating a winit event loop results in a hang.

fn main() {
    let _event_loop = winit::event_loop::EventLoop::new();

    tinyfiledialogs::message_box_ok("", "", tinyfiledialogs::MessageBoxIcon::Info);
    panic!("Doesn't reach here");
}

I've tested this with both tinyfiledialogs and nfd on Windows 10. Other dialogues like open/save file work fine (except when an existing file is chosen, since it brings up a confirmation message box).

This is on winit master d103dc2. It seems like 0.22.2 is okay with the message box, but panics afterward due to #1611.

@maroider
Copy link
Member

maroider commented Sep 8, 2020

Does your program hang indefinitely if you do the following instead?

fn main() {
    let event_loop = winit::event_loop::EventLoop::new();
    event_loop.run(|_, _, control_flow| {
        tinyfiledialogs::message_box_ok("", "", tinyfiledialogs::MessageBoxIcon::Info);
        *control_flow = ControlFlow::Exit;
    })
}

@branpk
Copy link
Author

branpk commented Sep 8, 2020

Yep. It also hangs regardless of whether or not a winit window is open and handling events at the same time.

@chrisduerr
Copy link
Contributor

I'd assume the dialog itself actually works? So you can interact with it and click it?

@branpk
Copy link
Author

branpk commented Sep 9, 2020

The message box actually doesn't display at all on master (sorry, should have mentioned that). In addition, it seems to even lock up the program that it was run from (VSCode, cmd, etc).

On 0.22.2 the message box displays and you can interact with it, but winit panics after it closes.

@maroider
Copy link
Member

maroider commented Sep 9, 2020

I did some bisecting, and dd866a7 (#1615) introduces the hang and makes the message box not show itself, which is consistent with what you've reported, @branpk.
It seems like things were working correctly up until the Windows event loop refactor in #1496 (b4c6cdf) got merged, at which point message boxes began making winit panic with thread 'main' panicked at 'either event handler is re-entrant (likely), or no event handler is registered (very unlikely)', D:\winit\src\platform_impl\windows\event_loop\runner.rs:236:18.

The lock-up of parent applications that happens when you experience the hang is likely due to how tinyfiledialogs uses MessageBoxW(GetForegroundWindow(), ...) instead of MessageBoxW(ptr::null_mut(), ...). native-dialog uses the second form, and does not trigger the lock-up.

blckngm added a commit to blckngm/titun that referenced this issue Sep 17, 2020
Because 0.22.2 will crash after the open file dialog is finished. It
seems to be this issue:

rust-windowing/winit#1698
@maroider
Copy link
Member

I tried attaching a debugger after the bug was triggered and it seems like it always gets stuck inside GetMessageW here when using native-dialog and tinyfiledialogs. The dialog library always gets stuck inside MessageBoxW.

A temporary fix would be to spawn your message boxes on a background thread.

@qthree
Copy link
Contributor

qthree commented Oct 22, 2020

I had similar problem with msgbox crate and solved it with a workaround from StackOverflow site: bekker/msgbox-rs#16

@maroider
Copy link
Member

maroider commented Nov 9, 2020

Pressing Alt seems to make the message box appear. This requires that you either don't change the focus after creating the message box or have a Winit window in focus.

@maroider
Copy link
Member

maroider commented Nov 9, 2020

Removing the WS_VISIBLE style from the "event target window" seems to make message boxes behave correctly, but that probably breaks something elsewhere.

@maroider
Copy link
Member

This issue didn't get linked from #1769, which seems to fix the issue for me.
That PR just got merged, so could you try using the latest changes on the master branch, @qthree & @branpk?

@VZout
Copy link
Contributor

VZout commented Nov 26, 2020

Ha I got good scare when I saw this in my PR:
chrome_IDtYEKCb3l

I thought I broke message boxes for some one else somehow😅

@branpk
Copy link
Author

branpk commented Dec 15, 2020

The bug seems resolved on master and 0.24.0. Thanks all!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants