Fix fullscreen window level corner cases on macOS #277
Conversation
Setting the level of a window again to the same level will put it in front of other windows on that level. Within each level it's the ordered index which decides the stacking.
The fullscreen_x() function can also be called for windows that are not receiving keyboard events (i.e. not in focus). In the cases where the window isn't keyWindow we should set the level to NSNormalWindowLevel. For keyWindows it's proper to set NSStatusWindowLevel like before.
When changing levels we need to make sure popup menus are properly stacked afterwards.
|
I don't have the possiblity to test the master branch right now, but from a quick glance, it seems that code has the same issues? |
|
Thanks for sending this PR. I'm not a macOS programmer (i.e. I don't know what's going on here) but anyway: I wanted to let you know that we do no longer accept patches (PR's) for Our macOS specialist @ManoloFLTK may chime in and tell you more about this topic. I can't tell if he will be able to apply your PR to 1.4 but I suggest to wait for a while before you may try to test 1.4 and maybe create another PR? That said, I see this is related to TigerVNC. Does TigerVNC still build with 1.3.x (only) or can you use 1.4 as well? |
|
As Albrecht explained, we no longer patch FLTK 1.3. |
|
Hi @Albrecht-S and @ManoloFLTK, thanks for your quick responses. Ok, I understand, with regards to Since FLTK 1.4 isn't available in the distros yet, I'm afraid TigerVNC has not made any attempts at building with 1.4. Until a release of 1.4 is available this will likely continue to be the case. Are you guys getting closer to a release? 🙏 |
|
Your name appears now as author of the code change. |
Thanks for this insight.
My hope is that we can release 1.4.0 by the end of this year or in Jan/Feb 2022, but that's just a guess. There's still a lot to do and we don't have a concrete schedule yet. |
|
We seem to be pushing the boundaries of FLTK with TigerVNC so a bit of a heads up would be appreciated. So some time for us to test an alpha or beta once a release is on its way would be useful. :) |
|
Sure, once we can "see light at the end of the tunnel" we'll post some kind of schedule somewhere (maybe in fltk.coredev, fltk.general, on our website, etc.). I'll also try to update the GitHub Milestones accordingly (this is still experimental, currently milestones are not yet maintained actively). |
|
It doesn't seem like this got included in the 1.3.8 release unfortunately. :/ Could this be added to the 1.3-branch now, in case there will be a 1.3.9? I see that there is already a commit post 1.3.8 on that branch. |
|
@CendioOssman and To TigerVNC people: could you, please, try the attached patch for FLTK branch 1.3 that intends to fix window levels.
The dock level is beween that for normal and that for fullscreen, key. I will commit that to branches 1.3 and 1.4 if I know it's OK for TigerVNC. |
|
Sure, I'll try to have a look at it this week. |
|
I'm afraid this patch does not work for us. Two major regressions right off the bat:
Tested on macOS 12. Some other notes:
|
That's fixed in the attached modified patch
What window is mentionned? What is the 'shielding level'? Do you mean that TigerVNC uses yet other levels than those FLTK uses? Please, explain in detail what you do in TigerVNC.
Yes, I should replace NSNormalWindowLevel by kCGNormalWindowLevel. I stopped using the Appkit constants because they are confusing in the sense that the doc says they are listed in ascending order but that' s incorrect when you consider each constant value.
Because a fullscreen window must cover the dock and the menu bar.
I changed levels to fix "BUG: Long menus on MacOS running off screen" that just appeared in fltk.coredev. Menu windows needed a higher level to cover the dock. |
I can verify that this works now.
Yes. We use
When it is key window, yes. But if it isn't then the code is supposed to have it at a normal level. Otherwise it might obscure the window that is actually key window. Btw, this doesn't work properly in my testing for some reason. When I switch to another window the full-screen window remains on top, obscuring the window I'm trying to use. This doesn't seem to be a recent regression as I see it in our TigerVNC 1.11.0 build as well. It did work at some point though.
I would suggest changing only that in that case and keep the code that checks other windows. |
It was broken by 25fc851. Might be a regression in newer versions of macOS. The issue seems to be that you always get |
|
Another effect of that bug is that dialogs for the full-screen window get placed behind the full-screen window when it doesn't have focus, and then magically reappear when focus is regained. Very confusing. |
|
OK. I attach a new patch that adds to 1.3 the code proposed at the beginning of this PR and that attempts to fix "BUG: Long menus on MacOS running off screen" by giving a higner level to modal windows (NSStatusWindowLevel instead of NSModalPanelWindowLevel). No other change. There remains a disagreement about non-key, fullscreen windows. Either:
I believe the 2nd view is correct because
@CendioOssman : We need to find a consensus view about non-key fullscreen windows. WIth the present code, modal and non-modal windows are located above fullscreen windows, so they are visible when shown. You mention "dialogs for the full-screen window get placed behind the full-screen window when it doesn't have focus". Does that mean that you use dialog windows that are neither modal nor non-modal? Would it be possible to set these dialogs either modal or non-modal? I would also need to know whether TigerVNC runs several fullscreen windows comtemporaneously. |
Yes, this patch seems to work correctly with TigerVNC. At least as far as not breaking anything that isn't broken before. It also makes TigerVNC work even when I remove our workaround for this issue. So the new fix in FLTK seems to work as intended.
I believe 1 is the only practical choice. If we choose 1. then we get some issues with the window that isn't focused. I.e. the window that isn't used. That is mostly cosmetic. With 2. we get the problem that I cannot do Cmd+Tab and use another application. At all. That's a major practical issue that should trump any cosmetic issues. Also, the code currently does 1. with a bunch of bugs. Not 2. I can still end up in situations where the full-screen window is behind the dock.
Only partially true. I'd rather say mostly false even. On Windows and X11 focused windows will be shown in front of the full-screen window. Even the taskbar can be shown in front of the full-screen window on Windows if you explicitly select it, e.g. by pressing the Windows key.
Nope. It's a modal dialog. It is shown on top of the full-screen window as long as it has focus. If I switch to another application the modal dialog is sorted behind the full-screen window.
Not for a single connection, no. But a user can open multiple connections. Each full-screen window would then be different processes. We might have multiple windows in the future though in order to deal with the multiple spaces setting. |
See long discussion in PR#277 at #277
See long discussion in PR#277 at #277
|
OK. I have committed to branches 1.3 (bc2f1f6) and master (1.4 - eeb3e92) the changes discussed here where non-key fullscreen windows return to the normal level in order to preserve the possibility to change app with command-tab. This also fixes the issue about long menu windows being below the dock. |
|
Great, thanks! Everything seems to work fine now. Even the issue with the modal dialog being placed behind the full-screen window when focus was lost is resolved. :) |
I'll begin with my understanding of the intended window levels from the
windowDidResignKeyandwindowDidBecomeKeyfunctions:NSNormalWindowLevelNSStatusWindowLevelOur application listens to
FL_SCREEN_CONFIGURATION_CHANGEDto be able to handle when a new monitor has been added while the window is in fullscreen. When this happens we need to call FLTK'sfullscreen_x()to enable fullscreen on the new monitor as well. The function needs to be called while the window already is in fullscreen.It's possible that this happens when the fullscreen window isn't keyWindow, and in this case the proper level seems to be
NSNormalWindowLevelinstead ofNSStatusWindowLevel.We also want to avoid re-stacking windows within the same level, this happens when setting level to the same value again. The window who's level was re-set will appear in front. This was already mentioned in a comment in
fixup_window_levels().Lastly, when the level of a window changes we should make sure the stacking is correct for modal and non-modal windows, this is done using
fixup_window_levels()on other places in the code, we should do the same infullscreen_x().