Multiprofile's Delete API modify

[yunate]

Before, we have implemented profile's Delete API, but it has some bugs, so we should modify it.

At present, the relationship between profile and WebView is:

1. One profile can have multiple WebView, those WebView can be in same process or different process.
2. InPrivate profile share same local file with normal profile.

So, when Delete API is called, we should raise an event handle to tell every webview2 under this profile that the profile has called Delete API.

Local files delete logic of Delete API will follow Edge’s delete logic. And the Edge’s profile delete logic is:

• The profile is marked as deleted, it not only in process memory, but also record in local file (%user-data-dir%/Local State). When the browser process exits, it will try to delete the marked profile, this may be failure for some file is occupied by some process or the browser process crashes, the truly delete action is not executed. Anyway, for some reason the local file may not be deleted successfully, in this case, when the browser run next time, it will check if %user-data-dir%/Local State file has recorded some profile is marked as deleted, if there is, it will try to delete again. If it still failure, next time the browser runs, it will check again until successful. When deleting local file successfully, it will remove the record from %user-data-dir%/Local State file. 

The Delete API new design is based on the above fact. When Delete API is called, the actions are: 

1. Close the webview2 under the profile.
2. Auto close the webview2 first, and then raise an event handle webview2.Closed to notify each webview2.
3. Profile creation will fail with the HRESULT is ERROR_INVALID_STATE(0x8007139FL) if create a new profile with the same name as a profile that is marked as deleted.
4. The local profile’s directory will be deleted on browser process exit or next start. 

[david-risney]

The two other cases we should add here (we can get the urgent work's implementation in first, and the less urgent parts implementation in a later PR) are for normal webview2 shutdown, and for browser process crash. Maybe this:

/// The CoreWebView2 has closed because the corresponding
/// CoreWebView2Controller had its Close method called either
/// explicitly or implicitly.
COREWEBVIEW2_CLOSED_REASON_SHUTDOWN,

/// The CoreWebView2 has closed because its browser process
/// crashed. The Closed event will be raised after the ProcessFailed
/// event is raised.
COREWEBVIEW2_CLOSED_REASON_BROWSER_PROCESS_FAILURE,

[yunate]

Ok, I will create a work item to trace this things.

[david-risney]

Additional entries for this:

/// The CoreWebView2 has closed because the corresponding
/// CoreWebView2Controller had its Close method called either
/// explicitly or implicitly.
COREWEBVIEW2_CLOSED_REASON_SHUTDOWN,

/// The CoreWebView2 has closed because its browser process
/// crashed. The Closed event will be raised after the ProcessFailed
/// event is raised.
COREWEBVIEW2_CLOSED_REASON_BROWSER_PROCESS_FAILURE,

/// The CoreWebView2 has closed because its browser process
/// has exited. 
COREWEBVIEW2_CLOSED_REASON_BROWSER_PROCESS_EXITED,

/// The CoreWebView2 has closed because its parent window
/// was closed.
COREWEBVIEW2_CLOSED_REASON_PARENT_WINDOW_CLOSED

[yunate]

Do I need to add those to the API SPEC, or add them one by one in a later PR?

[david-risney]

In addition we should add a property where you can check if the CoreWebView2 is closed or not. This way end dev's asynchronous code that may be in progress when the profile is deleted can check if the CoreWebView2 has closed and take appropriate action.

/// Returns TRUE if the CoreWebView2 is closed. Once closed, CoreWebView2 
/// events will no longer be raised and methods will immediately return failure
/// unless otherwise noted in the API documentation. This property will continue
/// to work after the CoreWebView2 is closed.
[propget] HRESULT IsClosed([out] BOOL* value);

[yunate]

I think do not need this function. Because, close webview and Closed event handle function called are in a same therad and a same loop. So, if the Closed event handle function called, the user has known the webview has been closed, they can record a flag in this function; if before Closed event handle function called, the webview is always still alive.

[leonhsl]

If developers explicitly called Close() to close the webview, wondering whether we need to raise the Closed event.

And, what scenario do you imagine that the Close() method is called implicitly? Is it already covered by other enums?

[yunate]

remove this Close event's Enum value and add them in latter PR.