Process Cocoa events after window close

[jqdg]

In recent versions of Mac OS, windows remain visible on screen ("stuck") even after closing unless events are processed. See glfw/glfw#1412 and this commit from the GLFW project. SFML also suffers from this issue.

This PR works around this issue by processing Cocoa events immediately after the window is closed.

Also, it adds a fix that should resolve #1581.

Example code to reproduce the issue (Mac OS only)

Without this PR, the window will remain visible even after it is closed (while waiting for using input from cin). With this PR, the window will be closed immediately (correct behavior).

#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
    sf::RenderWindow window(sf::VideoMode(1280, 720), "Minimal, complete and verifiable example");
    window.setFramerateLimit(60);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.display();
    }

    int x;
    std::cin >> x;
    
    return 0;
}

[eXpl0it3r]

Is this related or the same issue as #1581 describes?

[jqdg]

Is this related or the same issue as #1581 describes?

It's not really related, but I think that issue can be resolved with the following patch (I can add it to this PR if you want):

diff --git a/src/SFML/Window/OSX/SFWindow.h b/src/SFML/Window/OSX/SFWindow.h
index a59101a9..b3da579d 100644
--- a/src/SFML/Window/OSX/SFWindow.h
+++ b/src/SFML/Window/OSX/SFWindow.h
@@ -57,6 +57,16 @@
 ////////////////////////////////////////////////////////////
 -(BOOL)canBecomeKeyWindow;
 
+////////////////////////////////////////////////////////////
+/// \brief Allow to grab fullscreen events
+///
+/// See acceptsFirstResponder documentation above.
+///
+/// \return YES
+///
+////////////////////////////////////////////////////////////
+-(BOOL)canBecomeMainWindow;
+
 ////////////////////////////////////////////////////////////
 /// \brief Prevent system alert
 ///
diff --git a/src/SFML/Window/OSX/SFWindow.m b/src/SFML/Window/OSX/SFWindow.m
index ff60c6c5..507f258b 100644
--- a/src/SFML/Window/OSX/SFWindow.m
+++ b/src/SFML/Window/OSX/SFWindow.m
@@ -45,6 +45,13 @@
 }
 
 
+////////////////////////////////////////////////////////
+-(BOOL)canBecomeMainWindow
+{
+    return YES;
+}
+
+
 ////////////////////////////////////////////////////////
 -(void)keyDown:(NSEvent*)theEvent
 {
diff --git a/src/SFML/Window/OSX/WindowImplCocoa.mm b/src/SFML/Window/OSX/WindowImplCocoa.mm
index 091b7b2d..b4453a98 100644
--- a/src/SFML/Window/OSX/WindowImplCocoa.mm
+++ b/src/SFML/Window/OSX/WindowImplCocoa.mm
@@ -154,7 +154,11 @@ WindowImplCocoa::~WindowImplCocoa()
     // Put the next window in front, if any.
     NSArray* windows = [NSApp orderedWindows];
     if ([windows count] > 0)
-        [[windows objectAtIndex:0] makeKeyAndOrderFront:nil];
+    {
+        NSWindow *nextWindow = [windows objectAtIndex:0];
+        if ([nextWindow isVisible])
+            [nextWindow makeKeyAndOrderFront:nil];
+    }
 
     drainThreadPool(); // Make sure everything was freed
     // This solve some issue when sf::Window::Create is called for the

[eXpl0it3r]

Either added to this one or as separate PR, both would work for me.

Highly appreciated! 🙂

[jqdg]

Done. I added the fix to this PR.

[eXpl0it3r]

Successfully tested the originally mentioned issue.

Even though I can't reproduce the issue mentioned in #1581 the logic seems, to my little understanding of this, to be okay and does work.

[jqdg]

Thanks for the quick review!

I want to edit one of the Doxygen comments. Will it cause any issues if I force push to this branch?

[eXpl0it3r]

Not at all, that's actually our preferred way of operation! 😉

[eXpl0it3r]

Thanks a lot for these fixes! 🙂

If you see any other macOS things that can be improved let us, we're currently lacking some stronger macOS experience.