We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3766 - Mac OS X: SDL_WINDOW_FULLSCREEN is unset after using window controls to fullscreen-ify an SDL_WINDOW_RESIZABLE window
Summary: Mac OS X: SDL_WINDOW_FULLSCREEN is unset after using window controls to fulls...
Status: NEW
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.0
Hardware: All macOS 10.12
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-21 22:04 UTC by David Ludwig
Modified: 2019-04-28 20:00 UTC (History)
3 users (show)

See Also:

Attachments
code for sample application (794 bytes, text/x-csrc)
2017-08-21 22:04 UTC, David Ludwig 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Ludwig 2017-08-21 22:04:46 UTC 
Created attachment 2873 [details]
code for sample application

Clicking on OSX's green, 'make fullscreen' button (in modern versions of Mac OS X) on an SDL_Window, one which was created with SDL_WINDOW_RESIZABLE, will make the window appear to go fullscreen, however, subsequent calls to SDL_GetWindowFlags() on the window do not return values with the SDL_WINDOW_FULLSCREEN bit being set.

A sample application is attached.

Steps to reproduce:

 1. on a modern, OSX system (MacOS Sierra / 10.12 was used to reproduce this, however a couple of versions back should also work fine), create a Mac app that creates a windowed/non-fullscreen window, with SDL_WINDOW_RESIZABLE applied in the window's creation flags.

 2. wait for the app to finish launching.

 3. if using the attached sample app, observe that a yellow-filled window appears.  The yellow is used to indicate that the current app's window flags do not have SDL_WINDOW_FULLSCREEN set.  ('green' will be used to indicate SDL_WINDOW_FULLSCREEN being set.  This'll be important, later.)

 4. on the right side of the SDL window's title bar, find the green/maximize button (as provided by OSX).  Click on it.

 5. observe that OSX will make the window go fullscreen, and will also allocate a new desktop for it.

 6. wait for the window to finish going fullscreen.  Waiting a few seconds, here, should be sufficient.


Expected Results:
* if using the attached sample app, the now-fullscreen window's content will have changed to green.  The green indicates that SDL_WINDOW_FULLSCREEN has been set (whereas 'yellow' indicates no such setting).
* if not using the attached sample app, calling SDL_GetWindowFlags() on the SDL_Window, should return a value with the SDL_WINDOW_FULLSCREEN bit being set.

Observed Results:
* if using the attached sample app, the now-fullscreen window's content will still be yellow.  The yellow indicates that SDL_WINDOW_FULLSCREEN has NOT been set ('green' is used if and when that bit is set.)
* if not using the attached sample app, calling SDL_GetWindowFlags() on the SDL_Window, will return a value whereby the SDL_WINDOW_FULLSCREEN bit is NOT set.
Comment 1 Alex Szpakowski 2017-08-22 02:41:20 UTC 
This is intentional behaviour, I believe. Putting an app into its own Space intentionally doesn't do exactly the same as what SDL_WINDOW_FULLSCREEN_DESKTOP does (for example in fs-desktop the dock and menubar are always hidden).
Comment 2 David Ludwig 2017-08-22 12:45:00 UTC 
Regarding whether SDL_WINDOW_FULLSCREEN should be set/unset, perhaps.  This seemed non-obvious to me, and having a displayable dock and/or menu bar, alongside SDL_WINDOW_FULLSCREEN, does not seem mutually exclusive to me.  Perhaps with SDL_WINDOW_FULLSCREEN_DESKTOP, it should be, but I am uncertain of this.

On a similar note, after writing this up, I did notice a similar bug, whereby SDL_WINDOW_MAXIMIZED will often not get set, either.  This did not happen if and when I debug-stepped through the code, but did happen if I let the program run, without any breakpoints.  I presume the difference was a timing issue, given that it occurred in the same, Debug build, and always with a debugger attached.  If anyone likes, I could attach a modified version of the test program, to demonstrate this, and/or write up an additional bug report on it.
Comment 3 Alex Szpakowski 2017-08-22 15:37:53 UTC 
(In reply to David Ludwig from comment #2)
> Regarding whether SDL_WINDOW_FULLSCREEN should be set/unset, perhaps.  This
> seemed non-obvious to me, and having a displayable dock and/or menu bar,
> alongside SDL_WINDOW_FULLSCREEN, does not seem mutually exclusive to me. 
> Perhaps with SDL_WINDOW_FULLSCREEN_DESKTOP, it should be, but I am uncertain
> of this.

See also: https://hg.libsdl.org/SDL/rev/a2910aa6c056 (the original commit).

Fullscreen state is only set through programmatic means and it would break a lot of existing code if that changed. Putting a window into its own Space in macOS is not true fullscreen (or even fullscreen-desktop) in terms of what SDL defines it as, either, so there are multiple axes where the current approach makes the most sense, I think.
Comment 4 David Ludwig 2017-08-22 17:02:05 UTC 
As a point of reference, OSX's APIs do, in some ways, seem to treat an app that's getting its own space as if it were "fullscreen", at least in terms of API-naming conventions.  When the green, zoom control is clicked, OS X will end up invoking the windows' NSWindow*FullScreenNotification observers (NSWindowDidEnterFullScreenNotification, etc.).  OS X also appears to be toggling the NSWindow styleMask's NSWindowStyleMaskFullScreen flag: it sets it after going to fullscreen, and unsets it before going back to windowed mode (solely via use of OSX window controls).

Whether or not this should be 'fixed', I cannot say, however this does seem like a discrepency in what SDL2 reports.

For what it is worth, I struggled with this when working on the UWP backend, whereby the OS could, under certain circumstances, force a windowed-mode application into fullscreen.  SDL did not, at the time, appear very amenable to having its SDL_WINDOW_FULLSCREEN* flags be set, but it ultimately was possible, but arguably, might be buggy/unexpected.

I do, also, see some code in SDL's X11 backend that appears to detect changes to fullscreen state.  I'm not terribly familiar with that code, and am unsure, offhand, if it can modify an SDL_Window's flags, and if so, with what steps.
Comment 5 David Ludwig 2017-08-22 17:07:52 UTC 
Out of curiosity, what bugs could, or would come up, if SDL were to report fullscreen mode changes?

This does seem like a relatively new-ish, or just a rejuvenated thing, in window management, one that seems to becoming a bit more widespread these days.
Comment 6 David Ludwig 2017-08-22 17:29:34 UTC 
An additional note: in my testing, when using the zoom control, the Mac window does appear to be doing more than just maximizing: it resizes the window to cover the menu bar and the dock.  Both the menu bar and dock can appear, if and when the cursor is moved to either the top or bottom of the screen, however they are covered by default.

I wonder if there is warrant for new API(s) to SDL, here, to help with OS/WM-driven fullscreen/windowed mode changes.  I'm a bit hazy on what those ought to be though.
Comment 7 Edward Rudd 2019-04-28 20:00:33 UTC 
What about adding an SDL hint to control behavior?  As I see there are 3 behaviors that a developer may want.

1) The current behavior where it goes into a "fully maximized window but not considered fullscreen desktop" (e.g. can access menu bar and dock)
2) where it goes into a proper fullscreen_desktop (with all the same behaviors as FS Desktop.
3) disable/don't allow the fullscreen button in the window bar

I was working on updating a game for a developer and they noticed this (#1) behavior an didn't like it. they wanted the "green button" to behave like #2.   What I ended up doing is adding a "hack" to FORCE the collectionBehavior when the window is fullscreen to not add the 'full screen' so now it's a regular maximize (as the developer wanted the window resizable)

If I could get thoughts on this / confirmation that it's a good direction to go I can work up a changeset.