Avoid reconnection modal taking up entire screen, not being able to i…

[adamint]

Fixes #2514

This isn't the prettiest, please share your UI ideas if you have any, but this PR makes the reconnection modal centered, smaller, not see-through, and allows you to interact with the rest of the page.

I didn't want to remove the spinner nor the reconnection number count so overrode the existing styling of the ui container with !important, though we could also just create the container ourselves and hook into Blazor reconnection events to update the content.

Microsoft Reviewers: Open in CodeFlow

[leslierichardson95]

This looks good to me. While I kinda wish that the rest of the page was dimmed a bit, I understand the desire to be able to interact with the rest of the page so that's fine with me.

[tlmii]

In my mind there's a disconnect between this being (essentially) a dialog that covers part of the page when the page is not interactive and that dialog not being modal that makes me a little uneasy about this.

I get, though, that what we're trying to achieve here is a bit atypical. Most interaction with the page won't work. You can't click internal links, can't open settings, can't pick a different resource/metric/etc, can't expand the details panels, can't even scroll the logs pages since they're virtualized. So you're limited to reading and manually copying text from whatever information happen to be on the screen at the moment. And we can't really allow the latter without also allowing the former (or more accurately allowing the former actions to be attempted, since it won't work).

There's a tension between "making sure the user realizes why nothing they're clicking on is working" and "keep it out of the way of the user for when they need to read/copy info". If the latter were more important I'd say a yellow-bar style notification would be better. But I think that's actually the less common scenario.

You've done a good job of getting the dialog message out of the way of the content so the user can read/copy what they need while still making it obvious. I might tweak it a little bit (perhaps a very small shadow to separate it from underneath - particularly in the light mode - since there's no gray backdrop?; maybe a bit of internal padding for when the page gets small - see screenshot below?). But overall I think this is a fine improvement for the use case we're concerned about here.

[premun]

FWIW, I logged the original issue because I was unable to scroll to an exception in the log. So if we still have an invisible overlay that prevents interacting with the elements behind it, it's a little bit better but not quite solves the problem.

I agree with @tlmii that a yellow bar on top would be superior.

[adamint]

@premun there is no longer an invisible overlay with this PR. I believe @tlmii is saying the opposite, that he prefers this approach over a yellow bar. Could you confirm that, Tim? or whether I am misunderstanding 😄

FWIW if we want to do a yellow bar, we can do that pretty easily

[tlmii]

@adamint @premun On balance, I think the dialog approach Adam has is better because (in my opinion) "Ensuring people understand why they can no longer interact with the page" is more important than "ensuring the page is not obstructed at all" given how little interactivity is available while trying to reconnect.

@premun To clarify something that I may not have been clear on - in the implementation in this PR, there is no overlay that blocks interaction. But since this is (non-WASM) Blazor, and we're in the disconnected/trying to reconnect state, you can't interact with anything that isn't purely client side anyway. For instance, in your most recent synopsis of the issue "I was unable to scroll to an exception in the log" - you won't be able to scroll to the exception anyway (yellow bar or dialog) because the logs are virtualized and that requires the connection back to the server. If its already on the screen, you'd be able to read it and copy/paste it, so its good that this PR doesn't obstruct much, if any, of the log viewer.

[drewnoakes]

How does this look in dark theme?

[adamint]

dark theme @drewnoakes, same background color as before in dark theme 😄