Add Spec: Critical Restart Required #4657
Conversation
* add critical api --------- Co-authored-by: Diana Qu <xiaqu@microsoft.com> Co-authored-by: David Risney <dave@deletethis.net>
specs/CriticalRestartRequired.md
Outdated
| used to perform A/B testing or remotely disable features) configurations to toggle feature flags. | ||
| However, once these payloads are received, there is no way to restart the WebView2 and apply the | ||
| payload. The purpose of this API is to detect such critical payloads and inform the end developer | ||
| so they may restart their app or their WebView2 or other appropriate action. |
There was a problem hiding this comment.
Does "restart" mean e.g. AppInstance.Restart? Would help to show this in the example.
Is there a way to just restart the WV2 though?
There was a problem hiding this comment.
I'm also curious as to how much "restarting" is needed. For example, say there are two apps using WebView2 (call then X and Y). A critical restart is requested. X shuts down its WebView2 objects but Y does not. When X recreates its WebView2, it will still use the same WebView2 process pool as Y, which didn't restart. What happens now? Did the features change only for X and not Y? Did it change for both? For neither? Does X have to wait for Y to restart its webview2 before X can recreate its own webview2?
If X waits for BrowserProcessExited before recreating its webview2, could it be left stranded because Y never exits, resulting in an accidental denial of service attack against X? (Because X will be displaying a spinning "Please wait while we apply a critical update to your browser" forever?)
There was a problem hiding this comment.
If multiple apps are coordinating to share a user data folder and browser process then they must also coordinate to shutdown their webview2s at the same time. Otherwise like you say the same browser process will be running and it will still have the old configuration.
@dianaqu please ensure we mention this in the ref docs for the event.
There was a problem hiding this comment.
The section below this part already mentioned cases for sharing UDF
specs/CriticalRestartRequired.md
Outdated
|
|
||
| # Background | ||
| As WebView2 developers, we often have to author ECS (experimentation and configuration service - | ||
| used to perform A/B testing or remotely disable features) configurations to toggle feature flags. |
There was a problem hiding this comment.
A/B testing doesn't sound "critical" to me. Nothing goes wrong if the app doesn't restart their webviews.
There was a problem hiding this comment.
Yes. That's trying to define what ECS is. Not all ECS configuration updates are to solve critical issues.
There was a problem hiding this comment.
Do we want to talk about ECS in the public documentation?
There was a problem hiding this comment.
I was trying to avoid it that's why its only mentioned in the background. I thought it would be sort of confusing to introduce in the ref docs and we don't want to limit the event to just ECS
specs/CriticalRestartRequired.md
Outdated
| used to perform A/B testing or remotely disable features) configurations to toggle feature flags. | ||
| However, once these payloads are received, there is no way to restart the WebView2 and apply the | ||
| payload. The purpose of this API is to detect such critical payloads and inform the end developer | ||
| so they may restart their app or their WebView2 or other appropriate action. |
There was a problem hiding this comment.
I'm also curious as to how much "restarting" is needed. For example, say there are two apps using WebView2 (call then X and Y). A critical restart is requested. X shuts down its WebView2 objects but Y does not. When X recreates its WebView2, it will still use the same WebView2 process pool as Y, which didn't restart. What happens now? Did the features change only for X and not Y? Did it change for both? For neither? Does X have to wait for Y to restart its webview2 before X can recreate its own webview2?
If X waits for BrowserProcessExited before recreating its webview2, could it be left stranded because Y never exits, resulting in an accidental denial of service attack against X? (Because X will be displaying a spinning "Please wait while we apply a critical update to your browser" forever?)
specs/CriticalRestartRequired.md
Outdated
|
|
||
| # Background | ||
| As WebView2 developers, we often have to author ECS (experimentation and configuration service - | ||
| used to perform A/B testing or remotely disable features) configurations to toggle feature flags. |
There was a problem hiding this comment.
Yes. That's trying to define what ECS is. Not all ECS configuration updates are to solve critical issues.
specs/CriticalRestartRequired.md
Outdated
| used to perform A/B testing or remotely disable features) configurations to toggle feature flags. | ||
| However, once these payloads are received, there is no way to restart the WebView2 and apply the | ||
| payload. The purpose of this API is to detect such critical payloads and inform the end developer | ||
| so they may restart their app or their WebView2 or other appropriate action. |
There was a problem hiding this comment.
If multiple apps are coordinating to share a user data folder and browser process then they must also coordinate to shutdown their webview2s at the same time. Otherwise like you say the same browser process will be running and it will still have the old configuration.
@dianaqu please ensure we mention this in the ref docs for the event.
Co-authored-by: MikeHillberg <18429489+MikeHillberg@users.noreply.github.com>
An Critical Restart Required API to notify user for restart if needed