macOS native fullscreen should override transparency

[luciascarlet]

When using native macOS fullscreen, the background should always be forced to 1 opacity. macOS doesn't put anything but a plain grey background behind native fullscreen windows anyway, so the performance hit incurred by adding transparency (particularly if blur is used) can be spared in this situation. If you have desktop widgets, a blurred version of them continues to show behind the terminal.

[mitchellh]

I thought there was a discussion for this already where I agreed but I can’t currently find it so will use this one.

First off, I agree! There were counter arguments when this was previously discussed for people who wanted to see their wallpapers (but you’re claiming they don’t come through anyways).

As a point of diligence I’d love to do some research and ask what other terminals do on macOS namely Terminal app and iTerm.

Once some research is done I’ll convert to an actionable issue and tag it.

[luciascarlet]

I don't have iTerm installed at the moment, but as for Terminal.app, it indeed overrides the transparency setting you have in your settings and makes it fully opaque. For those who would like to see a wallpaper, I think it may be nice to have a setting to supply a background image that's always shown, or only shown when in fullscreen mode? Background images are a feature in quite a lot of terminals and I know some people like them a lot, although I personally don't use them.

[mitchellh]

Yep. I went ahead and just jumped into a PR because it's so simple. #2842.

[luciascarlet]

Unfortunately this isn't a complete fix :( At least for me, this only works if a new tab or window is opened in fullscreen mode, but not if you fullscreen an existing window. Likewise, if you exit a window that was opened in fullscreen, it will remain opaque. It should transition automatically. (macOS 15.1.1)

[mitchellh]

I am unable to reproduce this. Transitioning the windows is the only way I tested this I never even tried the other method of opening in full screen. Is there a race condition or something I’m not hitting?

The modification I made was to fire the callback only on transition…

[luciascarlet]

Here is a screen recording:

fullscreen.demo.mp4

Are you able to reproduce this when adding desktop widgets? In this video, you can also see that the window created during fullscreen becomes opaque when I restore it. It may be worth noting that I have two screens. Can you let me know if there's anything I could provide to help reproduce this?

[mitchellh]

Ah, the key was using the manual fullscreen button. I was using the keybinding. They go through different paths! I will take a look.

[rockboynton]

Native MacOS fullscreen is an option and works with Wezterm: https://wezfurlong.org/wezterm/config/lua/config/native_macos_fullscreen_mode.html
After seeing this issue, I checked and indeed it breaks in the ways described in the issue, when I use try to use widgets in the background. Strangely this persists even when removing the widgets and only starts working again randomly at some point.

With that said, it does work when not using widgets which I suspect most people do not use, so I still don't understand the logic behind disabling a setting the user explicitly set. A warning of this behavior, certainly. At the very least this would make more sense as an option, no?

[rockboynton]

Also, I found the thread I believe @mitchellh was referring to where he originally agreed:

If a user requests their window is transparent, then it's transparent. It's not our job to conditionally be transparent based on what you decide to put behind the transparent window.

from:#2545 (comment)

[mitchellh]

I reversed my opinion on this comment.

[mwmcode]

Fair point; which is why an option to toggle transparency like iTerm2's cmd + u would be great for those scenarios.

[sghng]

Several discussions suggested that there might be some bugs in this feature.

#5315 #5986