Application stuck when closing the window

[brcha]

Is your issue REALLY a bug?

• My issue is indeed a bug!
• I am not crazy! I will not fill out this form just to ask a question or request a feature. Pinky promise.

Is there an existing issue for this?

• I have searched the existing issues.

Is this issue related to iced?

• My hardware is compatible and my graphics drivers are up-to-date.

What happened?

I am evaluating the library and I've tried the counter example. When I close the window by clicking on the close button, the application never ends, it just stays running in the background until I kill it manually (Ctrl+C in the terminal). I've added printlns around the iced::application call, and indeed, the "after" println never happens. Here's a screenshot to illustrate that. On the latest release (0.12.1) application terminates normally when the window is closed.

What is the expected behavior?

I would expect the application to terminate when the window is closed.

Version

master

Operating System

Linux

Do you have any log output?

No response

[hecrj]

Are you sure a5b1a1d doesn't fix the issue?

[brcha]

I have iced.git = "https://github.com/iced-rs/iced.git" in Cargo.toml, and this commit has been merged. I was building outside of iced's source, so now I've checked out latest iced from git and built the example from there, and it still stalls when the window is closed. So, no, it doesn't fix the issue.

[hecrj]

Interesting. I can't reproduce, but I wonder if this may have to do with the Drop order of our Window instances in the window_manager module.

Could you try 6948c65?

[brcha]

I've just tried that. It didn't help…

[brcha]

I've added if window_manager.is_empty { break 'main } from v0.12 to your fix branch and now closing the window works.

[hecrj]

That is not a proper fix, since the application may need to exit even without a close request.

I believe you are not getting Destroyed window events for some reason. Try adding in line 930:

dbg!(&window_event);

[brcha]

I've added dbg at the start of the WindowEvent match and I do get the Destroyed event, but then the app continues getting keyboard events forever. Here's the output from the terminal (on the second run, when I promptly ctrl+c-ed it):

[winit/src/program.rs:924:25] &window_event = CloseRequested
[winit/src/program.rs:924:25] &window_event = Destroyed
[winit/src/program.rs:924:25] &window_event = ModifiersChanged(
    Modifiers {
        state: ModifiersState(
            CONTROL,
        ),
        pressed_mods: ModifiersKeys(
            0x0,
        ),
    },
)
^C

[hecrj]

You should be getting 2 destroyed events. One at the very beginning.

[brcha]

I've moved boot_window_closed = true to before the if and it closes correctly. That clearly isn't the fix either if I should get two destroyed events :)

[hecrj]

I imagine the boot window we use to initialize the Compositor may not be producing a Destroyed event in some platforms.

• Are you on Wayland?
• Does ce539c3 fix the issue?

[brcha]

Nope, I'm on X11. But that change does fix the issue.

[hecrj]

Well, then we know it's a winit bug for sure.

[hecrj]

I think c6d1a0e works around the bug without keeping a ghost window around and also should avoid prematurely exiting applications when a window is in the process of being opened.

Could you confirm it works?

[brcha]

Yes, it does work excellently. I also have a Mac and Windows machines, I could check if this change does break something on other systems, if you want.

[hecrj]

@brcha I have access to those platforms too. I don't see why it would break anything, however.

Thanks for the testing!

[brcha]

You are welcome :) Excellent lib, I am really excited for an Elm style UI in Rust.