If on server status screen, pairing request does not open until the status screen is closed.

[wwqrd]

If user is on the server status screen, then the pairing request dialog will not open until it is closed which means that they cannot pair.

Sounds like it could be obscured but also could be a re-rendering issue.

[wwqrd]

I've looked into this a bit further.

Modals currently have z-index set to var(--z--dialog), and the toasts manager has z-index set to var(--z-modal). This seems like it might be the wrong way around, but changing them might impact the other apps in unexpected ways, so hesitant to do that.

A local fix would be to override the styles (switch the z-index over) in Server, which works, but I'm not sure makes sense from a UX perspective?

[rebeccamadsen]

What happens when you click on pair with device? Does the pairing code dialog go over the network status dialog, or close it?

[jthrilly]

My view is that regardless of the current z-index values, toasts should be below dialogs, conceptually speaking. I think modal overlays (particularly when they contain a dialog) are supposed to be exclusive "single-task" interfaces, meaning that nothing else should take precedence over them until they are resolved. Successive modals now correctly take precedence over each other following a UI library change (I believe), so this should address your question @rebeccamadsen.

In practice I think this means that network status information is not suited to being displayed in a modal dialog. It isn't exclusive, and it isn't a task.

There are a couple of options:

• Given that we also have an issue with the main app window needing to be open in order for pairing requests to work, perhaps we should return an an earlier idea, which is to use native platform notifications for pairing requests. This would require handling the permissions flow for requesting notifications access on macos. Documentation here: https://www.electronjs.org/docs/tutorial/notifications We could potentially update UI to use platform notifications where available, and to fallback to the toast system when not?
• To resolve the network status issue, we could look at either (1) opening a separate browser window containing this information, or (2) using a different UI pattern. Opening a separate browser window seems to have precedent in other apps, and is the closest we can get to mimicking the "rich native modal" pattern. Alternatively, using something like an expanding panel, or even a rich tooltip shown on hover, would be simpler to implement and probably be just as good.
• Finally we want to resolve the z-index issue. I think modals should be --z-modal, with any dialog they contain also being --z-dialog. The toast wrapper should be --z-modal. The toast container always renders, so the DOM should set the correct stacking order (modal dialogs opened subsequently will cause the modal container to render after the toast container, with multiple dialogs rendering sequentially within it).

[jthrilly]

Closing, as no further development planned on Server.