Winit: Message boxes hang on Windows

Created on 7 Sep 2020  路  12Comments  路  Source: rust-windowing/winit

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.

Windows

Most helpful comment

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

All 12 comments

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;
    })
}

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

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

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.

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.

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.

I had similar problem with msgbox crate and solved it with a workaround from StackOverflow site: https://github.com/bekker/msgbox-rs/pull/16

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.

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

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?

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馃槄

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dhardy picture dhardy  路  3Comments

francesca64 picture francesca64  路  5Comments

JDTX picture JDTX  路  3Comments

swiftcoder picture swiftcoder  路  3Comments

chemicstry picture chemicstry  路  3Comments