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

Fullscreen borderless window does not exit on MacOS #2283

Closed
odanek opened this issue May 8, 2022 · 5 comments
Closed

Fullscreen borderless window does not exit on MacOS #2283

odanek opened this issue May 8, 2022 · 5 comments
Labels
B - bug Dang, that shouldn't have happened C - needs investigation Issue must be confirmed and researched DS - macos

Comments

@odanek
Copy link

odanek commented May 8, 2022

When window is created in the Fullscreen::Borderless mode setting control_flow to ControloFlow::Exit does not exit the event loop:

use winit::{
    event_loop::{ControlFlow, EventLoop},
    window::{Fullscreen, WindowBuilder},
};

fn main() {
    let event_loop = EventLoop::new();
    
    let window = WindowBuilder::new()
        .with_fullscreen(Some(Fullscreen::Borderless(None)))
        .build(&event_loop)
        .unwrap();

    event_loop.run(move |_, _, control_flow| {
        *control_flow = ControlFlow::Exit;
    });
}

Commenting out the .with_fullscreen(...) line does correctly exit the event loop.

Reproduced on:
winit 0.26.1
rustc 1.60.0
MacOS 12.3.1
MacBook Pro M1

@maroider maroider added B - bug Dang, that shouldn't have happened DS - macos C - needs investigation Issue must be confirmed and researched labels May 8, 2022
@madsmtm
Copy link
Member

madsmtm commented Jun 9, 2022

Can't reproduce on macOS Mojave 10.14.6, but may have been fixed in #2292, could I get you to check?

@odanek
Copy link
Author

odanek commented Jun 12, 2022

@madsmtm I can confirm that the issue is fixed on master. It probably wasn't fixed by #2292 though because I wasn't able to reproduce the issue even using the commit before the #2292 merge.

@madsmtm
Copy link
Member

madsmtm commented Jun 14, 2022

It would be nice to know which commit fixed it, would you mind running a git bisect to figure out which one? If you can't be bothered, that's also fine!

@odanek
Copy link
Author

odanek commented Jun 15, 2022

@madsmtm I have checked again and it has been indeed fixed by #2292, commit 4c39b31. Sorry for the confusion.

@madsmtm
Copy link
Member

madsmtm commented Jun 15, 2022

Wonderful, thanks for your help!

@madsmtm madsmtm closed this as completed Jun 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B - bug Dang, that shouldn't have happened C - needs investigation Issue must be confirmed and researched DS - macos
Development

No branches or pull requests

3 participants