Does the issue go away if you call

SDL_SetHintWithPriority(
    SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS,
    "0",
    SDL_HINT_OVERRIDE
);

before opening the messagebox?

(In reply to Ethan Lee from comment #1)
> Does the issue go away if you call
> 
> SDL_SetHintWithPriority(
>     SDL_HINT_VIDEO_MINIMIZE_ON_FOCUS_LOSS,
>     "0",
>     SDL_HINT_OVERRIDE
> );
> 
> before opening the messagebox?

Naturally this fixes it. I think what we'll do is add a reference count to X11 SDL windows, to track attached message boxes, and if it loses focus while one is attached, we refuse to minimize.

Should minimize-on-focus-loss even be the default at this point? I feel like all it does is cause bugs.

--ryan.

I'm curious to see if the focus loss and regain caused by the messagebox all happens in one frame - if so maybe we can just do the minimize action after all the events have been processed and the focus is still lost?

I've gotten occasional complaints about the minimize behavior but it seems like people like it for the most common case (alt-tabbing away from the game window), and the complaints were easy to resolve by having them add a line to ~/.bashrc or what have you.

So this specific problem (focus loss) can be quick-fixed as I described, I think, but the problem is actually a little deeper: the parent window still gets input events while the message box is running, and we don't process them until the message box is finished.

- Run Attachment #3848 [details]
- Hit the space bar to pop up a message box
- Click on the fullscreen window again.
- Hit the space bar a few more times.
- Click on the message box, click the button on it.
- Fullscreen window now gets all the events that have been queueing up...
- ...including the focus loss that happened when the message box was first created, so it minimizes itself in response.
- ...and then all those space bar presses, each one will pop up a new message box until it catches up.

If we set the window's override-redirect property, it won't get any input while the message box is running, but that has about a million disastrous side effects (it's really more for popup menus than message boxes). The message box is being marked as transient-for the parent window, correctly, but apparently this doesn't block input to the main window.

I'm going to go look at what GTK+ does here. We might just have to manually filter out a handful of specific events when the message box is finished, I don't know. Hopefully there's just an X11 protocol for this I'm not aware of yet.

--ryan.

(In reply to Ryan C. Gordon from comment #4)
> I'm going to go look at what GTK+ does here.

GTK+3 sets the message box window to be "transient for" the parent--as do we--but they also set _NET_WM_STATE for the message box window to _NET_WM_STATE_MODAL, to hint to the Window Manager that this is a modal dialog. This is the magic we're missing.

They don't set the message box window's _NET_WM_WINDOW_TYPE to _NET_WM_WINDOW_TYPE_DIALOG like we do, but I think that's probably okay.

(They also wire up an event handler to destroy the message box window if the parent window is destroyed, but that's a bug for another time.)

--ryan.

The input issues are now resolved by https://hg.libsdl.org/SDL/rev/7e37d3b5e7a3, but it will still get the focus events, so something like my quick-fix solution is now looking like the correct approach.

--ryan.

(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.

Moving all the remaining target-2.0.10 bugs to target-2.0.11. If these still aren't resolved when 2.0.11 ships, we should probably remove the keyword altogether.

--ryan.

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

For Bug #5106, I changed the default on SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS, which by extension fixes this issue.

--ryan.