Moving from WebView to WebView2 and handling localStorage/IndexedDB data.

[bryanwood]

Realise this is probably too soon and assumes a lot but figured I'd list the scenario.

I've got a scenario where I've got a deployed UWP/appx for my PWA in the store using the current WebView that's using localStorage and IndexedDB. Would this storage be able to be preserved or accessible somehow when moving to WebView2? I can see a scenario that might appear where I might "lose" data.

• User is offline and enters some data.
• User terminates application.
• User device comes online.
• Application is updated from app store.
• User opens application.

AB#27374585

[david-risney]

Thanks, great suggestion! This is definitely something we will think about working on the UWP WebView2 control. Thanks!

[verelpode]

Could you please also support the ability to delete the contents of the IndexedDB? This is absolutely essential in environments where the WebView2 needs to be prepared for use by a different user or staff member, such as kiosk computers used by multiple people. When one person finishes using the kiosk or WebView2, then it's important to clear all of their private data before the next person begins using it, otherwise private info becomes available to the next person.

In comparison, in WebView 1, the method WebView.ClearTemporaryWebDataAsync is very useful but unfortunately it's not fine-grained enough. Could you add options to choose exactly what kinds of data will be cleared? In particular, it would be good to make cache clearing optional because cache clearing is only sometimes required. In some environments, a lot of unnecessary traffic is produced by continual re-downloading of the same image files, etc, because of cache files being unnecessarily deleted when actually the intention was to delete user-specific/private info such as IndexedDB, cookies, saved passwords, form auto-fill data.

[liminzhu]

Particular to @verelpode 's comment, there are a couple of options I can think of -

1. [working today] you can create new WebViews from different user data folders to isolate user data. This comes with the most robust data isolation but ofc some perf concern as creating a new WebView environment and folder and what not for each new user is likely more expensive than recycling WebViews.

2. Like you mentioned, a clear user data function like WebView.ClearTemporaryWebDataAsync would be useful in your case. Not going to promise anything on the spot :) but we can consider something of that nature (@david-risney if I'm not mistaken we have a clear cookie item on the backlog but not all user data?). What I believe works today is you can clear stuff by calling CDP methods, which is more of a workaround than a permanent solution. We can certainly talk about the level of granularity and options we should provide in such an API. From what you wrote it sounds like you'd want to delete everything except for cached files b/c of perf? If you're only exposing your web content to your users, you can also consider shipping web content to with your app and loading it via file url rather than network.

[verelpode]

@liminzhu -- Thanks for the creative workarounds! When you say "different user data folders", do you mean like this:

1. Create a new user via one of the techniques such as System.DirectoryServices.AccountManagement.UserPrincipal (requires admin/elevated access; requires a background service running as admin).
2. Re-launch the current app, but make the new process run as the newly created user.
3. Delete the old/previous user account and user data folders.
4. Exit the current/previous app, leaving only the new process running as the newly created user.

That's an interesting creative solution, but it's also quite a significant amount of programming in order to make such a procedure work reliably in practice in a real environment.

HttpBaseProtocolFilter.CreateForUser is also an interesting idea but I think it doesn't affect IndexedDB, and I think it is only compatible with HttpClient, not with WebView 1 (WebView doesn't have an ability to pass a IHttpFilter instance to WebView).

Instead of a "run as user" mode, what we'd find much more useful is an ability to make WebView2 run in an "InPrivate" mode very similar to the InPrivate mode in the full Edge app. When an app uses WebView2 and instructs an InPrivate session to end, WebView2 would delete data applicable to that session, including IndexedDB, cookies, passwords, form data, where applicable to that particular session. And optionally also cached files. I've now posted this idea as issue #39.

We can certainly talk about the level of granularity and options we should provide in such an API. From what you wrote it sounds like you'd want to delete everything except for cached files b/c of perf?

You're right. Although I was thinking of bitflags similar to the granular bitflags in the old command rundll32.exe InetCpl.cpl,ClearMyTracksByProcess XXXXX, this level of granularity might be more granular than necessary. I don't know what granularity other people need, but in our case, what you said meets our current requirements. However in the case of what @bryanwood said, it sounds like he'd want IndexedDB writing + clearing to be separate from cookie clearing.

If you're only exposing your web content to your users, you can also consider shipping web content to with your app and loading it via file url rather than network.

That seems like a good solution for some environments, but not for our environment where the enterprise websites have many dynamic webpages that read and write databases, and the websites are created by different groups independent of our group.

[liminzhu]

Oh I should have been clearer :). When you create a WebView environment before creating a WebView, you can specify where to put the user data folder. I was thinking when your app switch to a new user, you tear down the current environment & WebView and create a new one.

[liminzhu]

Instead of a "run as user" mode, what we'd find much more useful is an ability to make WebView2 run in an "InPrivate" mode very similar to the InPrivate mode in the full Edge app.

This is a really interesting idea and it occurred to me when I was reading your initial comment too! What holds me back is with InPrivate, you still have to write up logic to tear things down when a user session end and create new WebView for another upcoming user. It isn't much different from creating another webview from a new user data folder and deleting the old one, which you can do today.

That seems like a good solution for some environments, but not for our environment...

Totally understand, just a suggestion in case it can work :). It could take us some time to come up with a good solution proposal, but I want to capture the scenario/requirement first. Feel free to correct me if I'm wrong,

Priority 1 - WebView API needs to support a workflow for isolated user session. When a previous user is finished, WebView cannot leak any data from previous user to the next. Priority 2 - While user data should be isolated, it'd be great if non-sensitive cached resources such as images can persist.

[liminzhu]

Also back to @bryanwood 's original request, are we talking about preserving browser state (IDB and localStorage in this particular case) when migrating from current in-market EdgeHTML WebView to WebView2? If that's the case we should probably separate those different requests into 2 issues 😃.

[verelpode]

@liminzhu

When you create a WebView environment before creating a WebView, you can specify where to put the user data folder.

Aha! I'm still learning the differences between WebView2 and WebView 1. I'll post my reply in issue #39 because it's diverging too far away from @bryanwood 's original request.

Totally understand, just a suggestion in case it can work :).

Absolutely. Other people who read your suggestion will definitely find it helpful, as it's a good idea for environments where that suits.

[liminzhu]

Aha! I'm still learning the differences between WebView2 and WebView 1. I'll post my reply in issue #39 because it's diverging too far away from @bryanwood 's original request.

No problem, we're here to help with any questions :D.