There’s a wide diversity of types of windows used on Macs. In addition to standard windows used as a mainstay by most apps, there are specialists that behave differently, among them traditional Help windows displayed and managed by Help Viewer. Not all Help windows even use that: just looking at those in my own apps, some rely on Help Viewer, others are just regular windows containing styled text or PDF.

Ventura’s Stage Manager doesn’t cope equally well with all these window types. In comments here, Bernie kindly drew attention to problems it experiences with windows intended to remain in front, on Apple silicon Macs. This article explains what goes wrong, how to deal with it, and where the bug is likely to be.

Help on Intel and Apple silicon

If you have access to both Intel and Apple silicon Macs, you may have noticed that Help windows displayed by Help Viewer differ in their behaviour between the two architectures. On Intel Macs running recent versions of macOS, those windows don’t work well. In some cases, they take a long time to open, occasionally failing altogether, and when they do work they normally get left at the back, where they’re hard to find. Yet on M1 and M2 models, they seem to behave like they used to, are put at the front, and work more reliably.

On Intel Macs, opening a Help book that’s managed by Help Viewer doesn’t bring the Help window to the front, and that window is treated by Stage Manager as if were just another window owned by its parent app. When minimised or put back into the Cast, it does so independently of its parent, although it will remain on Stage when the parent app is brought on Stage.

Behaviour on Apple silicon Macs running macOS 13.1 and 13.2 is quite different, with the Help window being placed in front where it floats independently of the app. There it seems to have its own app, presumably Help Viewer, and goes into its own group in the Cast. And that’s where it can cause problems: clicking on the yellow Minimise control at the top left of the Help window can stop Stage Manager in its tracks.

What happens

To demonstrate this with Stage Manager enabled on an Apple silicon Mac, empty the Cast apart from a Finder window or two. Open Safari, then open Safari Help from its Help menu. Switch between Safari and the Finder on Stage and you’ll see that Help window remains on Stage whatever else you put there.

With the Help window on Stage, click on its Minimise control. Everything currently on Stage is put into the Cast, and no matter which member of the Cast you then click on, none can be brought onto the Stage. Stage Manager has stalled.

Looking carefully at the Cast, that for the Help window isn’t quite right, with its miniature app icon shown behind the window itself, as if the window has to remain on top even here.

Workaround

Resolution of this impasse is to turn Stage Manager off and close that Help window, then turn Stage Manager back on. You can avoid this by not minimising Help windows, and leaving them on Stage until you close them.

This can also affect other windows intended to float on top of everything else, but doesn’t affect Help windows that aren’t managed by Help Viewer.

Mechanism

Log entries for one of these failed attempts to bring one of the Cast onto the Stage start normally.

Here’s the initial click:
0.647586 trackMouse send action on mouseUp
0.647588 sendActionFrom:
0.647623 sendAction:

That’s followed 0.002 seconds later by what appears to be a normal sequence of entries typical of this action:
0.649341 com.apple.windowmanagement Ordering <private> above relative to <private>
0.649446 com.apple.windowmanagement App window has been ordered above nil in space 0x1; stage needs to be visible.
0.650672 com.apple.SkyLight <private> Taking cursor environment
0.651207 com.apple.SkyLight <private> Showed cursor
0.651412 com.apple.windowmanagement handleMiniaturizeAction for: <private>
0.653221 com.apple.windowmanagement Stage windows did change: <private> -> <private>
0.654113 com.apple.windowmanagement [<private>] '<private>' activity did begin

After a significant delay of over 0.02 seconds, SkyLight starts tracing stalls that have apparently led to this action failing, with entries like:
0.678996 com.apple.SkyLight tracing.stalls Signpost ID is context_id. pid=1384 frame_seed=0x1466 display_id=0x1 earliest_mct=24640172683 process_name=/System/Library/CoreServices/HelpViewer.app/Contents/MacOS/HelpViewer transaction_seed=0x4e

The following processes are identified during this tracing:

• /System/Library/CoreServices/HelpViewer.app/Contents/MacOS/HelpViewer
• /System/Volumes/Preboot/Cryptexes/App/System/Applications/Safari.app/Contents/MacOS/Safari
• /System/Library/CoreServices/SystemUIServer.app/Contents/MacOS/SystemUIServer
• /System/Library/CoreServices/ControlCenter.app/Contents/MacOS/ControlCenter
• /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer
• /System/Library/CoreServices/Dock.app/Contents/MacOS/Dock
• /System/Library/CoreServices/HelpViewer.app/Contents/MacOS/HelpViewer
• /System/Library/CoreServices/WindowManager.app/Contents/MacOS/WindowManager
• /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder

Eventually, WindowManager reports the activity complete, and installs blocking overlays as normal, as if the action had taken effect rather than failed.
1.504465 com.apple.windowmanagement [<private>] '<private>' activity did complete
1.504674 com.apple.windowmanagement Installing gesture blocking overlay 47 for 100
1.505507 com.apple.windowmanagement Installing gesture blocking overlay 103 for 76

Somewhere in the chain between Help Viewer and WindowServer, there’s a bug. What’s more, that exists only on Apple silicon Macs, and not on Intel models, which behave quite differently and don’t manifest this problem at all. At this stage, we tend to assume that, apart from hardware access, code running on the two supported architectures is essentially the same. The evidence with Help Viewer and WindowServer is already starting to show significant differences, as here.

Currently, Intel Macs appear to be running an older and unimproved version of Help Viewer than Apple silicon, and retain their old flaws but work well with Stage Manager. Apple silicon Macs have better-behaved help, but that means they don’t work as well with Stage Manager.

Stage Manager currently has other problems with different types of windows, although those usually affect both architectures. For example, apps based on AppKit normally form persistent window groups, remembered by Stage Manager between launches. But some apps using SwiftUI, like the Twitter client, don’t persist at all, and have to be added to groups every time they’re opened.

I will be reporting this bug using Feedback, so it can get fixed as Stage Manager matures.