MacOS Ventura Stage Manager Bug or My Bug?

Targets macOS
1

Hi. I’ve got a rather odd problem. The problem is about a Mac application created on a Mac using the most current Xojo 2022r31, and on the latest Mac Ventura when Stage Manager is ON.

I have a program that has a main window. If you click a button on the window, a modal dialog pops up (call it ModalDialog-1, MD1), if you press a button on MD1, a different modal dialog pops up (MD2)…when you dismiss MD2, the focus returns to MD1, and when you dismiss MD1 the focus returns to the main window. Perfect. At least, that’s how it’s worked for years on a program (programmed with an earlier version of Xojo.) And, it works the same way as it always had when I re-do the program using the latest Xojo2022r31.

But, a problem appears if I merely turn on Ventura’s Stage Manager (activating it using the Control Center icon in the MenuBar). As soon as Stage Manager becomes active, this is what happens…

In my app’s main window, click to get MD1, then click in MD1 to get MD2…(so far so good) but now if you dismiss MD2 the focus goes back to the main window (NOT MD1). The MD1 window is still on the screen and should be the active window but the active window is the main window NOT MD1. (And, if my app happens to have another (non-modal) window open, the focus might go to that window, again with MD1 still standing there without focus.) A dangerous situation.

One fix is easy. Just turn Stage Manager off. But, of course, that’s hardly a fix.

So, the question is, did I just find a bug in Ventura’s Stage Manager’s handling of windows and dialogs, or did Stage Manager just expose a bug in my own handling of windows and dialogs (that’s been with me for years!)? Might I be using Dialog windows that aren’t sanctioned anymore or some such thing? The program’s worked for a decade and more as it should, and only with Stage Manager On does it mess up. Curious, eh?

And, to add a bit more to the story, I was able to fix this issue no matter the origin of the odd behavior. I added a “MD1Window.Show” to the code after the MD2 modal dialog is dismissed. Now, the program works as it should whether Stage Manager is on or off. But, why should I have to add the Window.Show explicitly. In all times past, I never had to do that. The Mac would just automatically put the focus back to the window or dialog that called the modal dialog.

Anyway, I do have the fix, but it’s still a mystery why this is happening, and I just don’t know yet whether the problem I fixed was mine or Apple’s. Any thoughts appreciated! THANKS!

2

Create a simple sample, with 2 chained modals as your app has, showing the issue, and report it to Xojo. This needs a fix, the causes Xojo will find out, Apple side or Xojo side.
Looks like that under Stage Manager MD2 loses its MD1 parent window. https://xojo.com/issues

3

Stage Manager is still buggy according to some Swift developers, so there’s a chance that it might not be anything you’re doing wrong. Bear in mind that Stage Manager is an iOS first feature that’s been ported to the Mac, not a Mac feature ported to iOS, this reverse direction (like the iOSficication of the macOS) creates a lot of problems.

Have you considered making the modal dialog a sheet? This way you can attach it directly to the window. I don’t know if it will help, but it might be worth a try.

4

Thanks Rick and Sam. A sheet is a really good idea. I might try it just for fun, but my goal right now isn’t really to redesign how things work just to figure out if the problem I see is on my end or Apple’s? (and Rick even mentioned that the problem could be on Xojo’s end…that hadn’t even occurred to me since the problem appears when I released the program with a much older version of Xojo as well as trying it with the latest Xojo. But, you never know. Time will tell.)

5

Are you using .Show, or .ShowModal?

Show could conceivably cause issues.

6

When I invoke the modal dialog, I use MD2.ShowModal. When it returns, my (temporary?) fix is to then do a “MD1.Show” which puts the focus (if that’s the right word) back on the window that invoked MD2 (which used to happen without having to do the Show but with StageManager ON, that would force the correct window to be active, and also works with StageManager Off…so for now, not knowing why, this fix seems to work).

7

As I said, create a sample and let Xojo have a look at it. The outcomes will be something like “Oh! We found a problem here, fixed for the next version” or “Everything seems ok, that’s probably a Ventura bug and we will report it to Apple, let’s wait it being fixed in a Ventura dot release”.

8

You’ve been lucky through time that this has worked for you without doing just that.

It would be far more obvious if you were also coding for Windows and Linux. The Stage Manager flow is seen there almost every time with the parent non-Modal window being reset as the focus recipient.

1 Like
9

WOW! Blunt and to the point. Thanks. If what you say is true, I most certainly do have a lot of work to do fixing up past and current programs. I believe I have routinely just used a SomeDialog.ShowModal and just assumed that when the modal dialog is finished, the window that invoked the modal dialog is automatically back to being the active window. You’re saying I should explicitly do a InvokingWindow.Show immediately after each call to invoke the modal dialog. If true, that would explain everything because until trying to fix this “Stage Manager Bug”, nothing exposed my error!

That said, I wonder if you can find (I haven’t been able to so far) documentation that suggests I handle modal dialogs in that manner.

10

Sorry Ken, didn’t mean for that to come across so blunt :grimacing:. My discovery of this was through trial and error. In fact, at one time back in the teens, I was told not to launch a modal window/dialog from another modal window/dialog - and, in doing just that in a number of cases, the second modal would not gain focus from its parent, making the whole app appear to be locked up. The user can’t respond to MD2 because MD1 has the focus, and the user can’t respond to MD1 because MD2 has the Modal lock … the race is on!

Answering further, I’ve changed my code to either not require a modal child of an existing modal, or using a sheet window and then calling the second modal window from the sheet.

On one particular “Wizard-style” guided steps dialog, I’ve added a PagePanel and then step through the pages as the user responds to each step.

11

No problem. I most definitely appreciate bluntness, especially if you’re right, and I have no reason to assume otherwise. And, to be honest, I know that putting up a modal dialog from a modal dialog is not exactly good form, but that’s what the program in question has done for so many years, so I’m trying to fix it “as is” for the moment anyway. That same MD2 that is causing the problem in the case mentioned, does NOT cause a problem elsewhere when used. So, it MIGHT just happen only when a modal dialog invokes a second modal dialog.

I hope to happily go back to all my modal dialogs and follow them with an explicit Show of the parent window…but I sure would love to find some documentation showing that’s what always should be done after invoking a modal dialog. (I know what ASSume implies, but I just always thought when a modaldialog returns you never have to explicitly tell it where to return to…that it naturally returns to wherever it was that called it.)

1 Like
12

Hi Rick…thanks for the pointer to the xojo.com/issues. I just uploaded a new issue (named the same as the title of this thread) along with a sample project that demonstrates the problem. A crude test, but I hope it will be sufficient to show the problem.

13

:+1:t2:

14

Hi Rick and/or others. I posted an issue as recommended on the xojo.com/issues web site. Someone (Robin) read it and required more info…and the label read “Information Required”. Robin asked for a simple procedure to show what I found and maybe a movie. I supplied both, but haven’t heard back. Am I just in a waiting game until Xojo gets back around to this issue, or was it my mistake? Was I supposed to somehow change the label from “Information Required” to “Information Provided” or some such thing. If so, I wonder if you know how I do that. Otherwise I just wait. Thanks!

15

The issue will be reviewed again. If they can reproduce it it will be adjusted to Reproducible and be put on the queue to be fixed.

If it still cannot be reproduced you may get asked for further details. Stick with it and eventually you should get there. The important thing is reproducing the problem. It is so much easier to correct a problem you can reproduce.

16

Thanks Ian…so for now, doing nothing is what I can do…I’m good at that! And, I do think the problem is easily reproducible. I just need to know if the problem is with Apple’s Stage Manager, or with Xojo, or cockpit error on my part. Thanks for the clarification.

17

Keep in mind that Xojo apps are not yet compiled against the macOS 13.x SDK, so it could simply be that the apps can’t do this “right”. They usually make that change once .1 or .2 is released unless there’s some really important change that requires it (like declares that you can’t use without them).

18

Being pedantic here, but I think it’s a good idea to get the terminology right.

You Fix bugs that you create, you Workaround bugs that Apple and Xojo make, as you don’t have the capability to go into Apple’s or Xojo’s frameworks and fix 'em. Even if you hack into an Objective-C class and redirect methods to your own creation, which solve the problem within your application, you’re still working around someone else’s bug.

Someone else’s bugs are your problem, but they’re not your doing. They’re not your fault, unlike bugs in your code.

As time goes by, you’ll end up finding more bugs and providing workarounds for them, especially if you continue developing for Apple PJ platforms.

1 Like
19

I long ago discovered you can’t do a modal on top of a modal and molded my design around that fact. If you’re Mac only, you should be able to get away with it.

20

Thanks for the comments, Greg, Sam and Tim. Much appreciated. And “pedantic” is fine…it’s amazing what you learn on this forum.

The program I wrote where I discovered this problem that only showed itself when Stage Manager is turned on, is indeed a Mac only program.

And maybe repeating myself a bit, but my main goal is trying to find out if this problem is a Stage Manager problem, a Xojo problem or my own problem.

I already have a “workaround” (as Sam would likely have me say) for the problem. But, the workaround is bothering me. In brief, I always thought that when you close a ModalDialog, control returns to whatever window invoked the modal dialog. I thought you did NOT have to explicitly follow the return of a ModalDialog with explicitly “Showing” the window that invoked the modal dialog.

Anyway, I look forward to what Xojo has to say about the matter.