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

BorderlessFullscreen does not cover the menu bar on macOS #14783

Open
TarekAS opened this issue Aug 16, 2024 · 2 comments
Open

BorderlessFullscreen does not cover the menu bar on macOS #14783

TarekAS opened this issue Aug 16, 2024 · 2 comments
Labels
A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior O-MacOS Specific to the MacOS (Apple) desktop operating system S-Blocked This cannot move forward until something else changes

Comments

@TarekAS
Copy link

TarekAS commented Aug 16, 2024

Bevy version

0.14.1

Relevant system information

cargo 1.80.1 (376290515 2024-07-16)
macOS Sonoma 14.5

Automatically hide and show menu bar is set to Never in the system preferences.

What you did

Basic bevy app with BorderlessFullscreen enabled, running on macOS.

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins.set(WindowPlugin {
            primary_window: Some(Window {
                mode: bevy::window::WindowMode::BorderlessFullscreen,
                resolution: bevy::window::WindowResolution::default(),
                ..default()
            }),
            ..default()
        }))
        .run();
}

What went wrong

Expectations: BorderlessFullscreen should cover the entire screen.

What actually happened: it didn't cover the menu bar

Additional information

image

Hovering near the menu bar also exposes the title bar
image

If this is not considered a bug, perhaps there should be an option to cover the entire menu bar as well.

@TarekAS TarekAS added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Aug 16, 2024
@alice-i-cecile alice-i-cecile added A-Windowing Platform-agnostic interface layer to run your app in O-MacOS Specific to the MacOS (Apple) desktop operating system and removed S-Needs-Triage This issue needs to be labelled labels Aug 17, 2024
@alice-i-cecile
Copy link
Member

Can you reproduce this in winit itself? I suspect this is a bug upstream: once reproduced there please open an issue on their repo and link it here (or vice versa).

@alice-i-cecile alice-i-cecile added the S-Blocked This cannot move forward until something else changes label Aug 17, 2024
@TarekAS
Copy link
Author

TarekAS commented Aug 17, 2024

I investigated a bit and here's what I found:

  • I can confirm it's an issue with winit by simply trying one of their examples here and setting it to fullscreen using Ctrl+F, which triggers BorderlessFullscreen mode.
  • It used to be the case that BorderlessFullscreen hid the menu bar, but it was fixed in version v0.26.0.
  • The documentation around set_fullscreen is a bit weird. It says that Fullscreen::Borderless is the idiomatic way for fullscreen games to work on macOS, but it also says only Fullscreen::Exclusive disables the menu bar and the dock, which is a bit of a contradiction.
  • There is an open issue (Expose window 'surface' size, distinct from the 'inner' size rust-windowing/winit#2308) that seems related to this.
  • A comment in the winit codebase seems to hint that it is not configurable for consistency purpose

It turns out I had set Automatically hide and show the menu bar to Never in my settings. However, in a bevy game, this should ignored and the menu bar should be hidden either way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior O-MacOS Specific to the MacOS (Apple) desktop operating system S-Blocked This cannot move forward until something else changes
Projects
None yet
Development

No branches or pull requests

2 participants