Winit: Fullscreen Titlebar Won't Show on macOS

[nixpulvis]

While in an exclusive fullscreen mode on macOS, the titlebar (while hovering over the top of the screen) doesn't slide down as expected. I've confirmed this issue with cargo run --example window from this repo. This issue seems to have been introduced in 5bc3cf18d98aef0a5f0a51c0cf655d37af833730 with the merge of #925.

This was originally brought to our attention in https://github.com/jwilm/alacritty/pull/2438#issuecomment-536649468.

[ghost]

This is because we currently set the NSApplicationPresentationOptions as such that the menu bar is hidden in exclusive fullscreen. See window:willUseFullScreenPresentationOptions:. We should check if the window is in borderless fullscreen mode and not set these flags in that case. Additionally, a way should be added to set NSApplicationPresentationOptions to user-specified options when the window is in borderless fullscreen.

[Osspial]

@vbogaevsky could you look into resolving this?

[nixpulvis]

I've taken a short look at this, and I'm by no means a real macOS developer but...

Simply passing through the currently unused _proposed_options as the return value of window:willUseFullScreenPresentationOption seems to give us the behavior we want in Alacritty. Though it seems we don't even try to allow a user in a non exclusive fullscreen mode to even attempt to transition into an exclusive fullscreen mode (thus sidestepping the whole CGShieldingWindowLevel() + 1 hack).

I'd be curious to know what a macOS user/developer has to say about this, since the whole way fullscreen works on macOS seems a bit crazy to me, it's hard for me to know how I'd expect this all to work.

I think I can say however that for exclusive fullscreen (not necessarily the same for non exclusive) it's not acceptable to always hide the menubar. This is partially supported by the fact that the green button in the traffic light UI typically means "toggle exclusive fullscreen", and a user who clicks that button to get into this mode, will be helpless to exit it.

[ghost]

I think you may be confusing exclusive fullscreen and borderless fullscreen. Borderless fullscreen is what the user ends up in when they click on the green icon on the window decorations. Exclusive fullscreen is a video mode change and locks the display so that app switching is disabled. The reason we're hiding the menu bar in exclusive fullscreen is to avoid graphical glitches with regards to it. In borderless fullscreen we shouldn't be hiding the menu bar by default.

The fix here is simple—in window:willUseFullScreenPresentationOptions: we return proposedOptions if the window is not in exclusive fullscreen mode. If the window is in exclusive fullscreen mode, to avoid graphical glitches we must return NSApplicationPresentationFullScreen | NSApplicationPresentationHideDock | NSApplicationPresentationHideMenuBar.

I would like to make this customizable though, e.g. a set_fullscreen_presentation_options method on WindowExtMacOS whose value (if specified) is used instead of proposedOptions in borderless fullscreen. This allows applications to still hide the menu bar and the dock if desired, such as is often the case for games. For exclusive fullscreen we should always hide the menu bar, and thus ignore this value.

[nixpulvis]

@aleksijuvani, oh interesting I think I was assuming that exclusive would be the mode where you give an application "exclusively" its own "space". And borderless would be the mode where you can still share a space, it's just fullscreen over everything (like video players fullscreen).

In Alacritty, we call these modes Fullscreen and (only on macOS) SimpleFullscreen respectively.

Regardless, your comments do make this sound simple to fix the non-borderless case. I can see about opening a baseline PR today.

[ghost]

The names we chose for the fullscreen modes on macOS aren't great, but that's because fullscreen on macOS doesn't match exactly how fullscreen works on other platforms. To summarize, there are three fullscreen modes on macOS:

1. "Exclusive fullscreen", i.e. native fullscreen + video mode switch + lock display. This is generally only used by video games that want to draw directly to the screen at a specific resolution and wish to avoid an additional blit caused by rescaling the framebuffer to the native resolution
2. "Borderless fullscreen", i.e. native fullscreen, which is what happens when you click the green button on the window decorations
3. "Simple fullscreen", which essentially just hides window decorations and sets the bounds of the window to match the bounds of the screen. This was added because there are power users who do not like the behaviour of native fullscreen on macOS (because it moves the window to its own space)

Generally "borderless fullscreen" should be preferred by applications unless there is a strong reason to use one of the other modes.

[felipesere]

👋 I'm not really a macOS dev but I do use run Alacritty on macOS daily.
Not having the menu bar is annoying enough by now that I'd be happy to give this a try myself.

Would anyone be able to mentor me through it though?