Support for Browser Profiles (extension of Tauri issue #9285)

[zphrs]

Is your feature request related to a problem? Please describe.
I would ideally like to be able to create separate browsing profiles to segment Cookies, localStorage, and IndexedDB data into different profiles. Here are some use cases which could benefit from this feature:

• Supporting multiple account login without any further server-side development
• Local-first applications like Excalidraw which typically stores user data within either localStorage or an IndexedDB table
• To limit third party tracking mechanisms across different webviews

The above use cases are very similar to the use cases for the data_directory() api. However, as I noted in the Alternatives considered section, the data_directory() api is not supported on MacOS.

Describe the solution you'd like

Platform-Specific Implementation Details

In macOS 14 and iOS 17 Apple has released new DataStore APIs which should enable this feature.

In Windows Microsoft has released new Multiple Profile Support which should enable this feature.

I assume we can polyfill this feature to WebkitGTK (and Android) using the existing implementation used for setting the data_directory. Ideally the polyfill would create additional subdirectories within the default data directory to support the different profile names. For private profiles (i.e. incognito windows) which shouldn't be persisted I propose the use of the tmp directory to store those temporary profiles. While we won't get the performance advantages listed below in the Alternatives Considered, a polyfill will at least allow some support in the interim before GTK and Android supports browser profiles.

Proposed Changes

WebviewProfile

I propose the addition of a new struct called WebviewProfile which will store all of the necessary references and metadata needed for the profiles. It should have the following functions:

• WebviewProfile::default() -> WebviewProfile returns the default profile.
• WebviewProfile::private() -> WebviewProfile returns a temporary profile.
• WebviewProfile::new(name: String) -> WebviewProfile returns a new profile, storing the display name as metadata. It will not check whether the name has been used before as that would require access the the App state.
• WebviewProfile::filePath(&self) -> Option<Path> returns Some(directory) where all of the user data is stored if it isn't private, otherwise returns None. Note that this option resolves the complaint (#8635) around trying to locate where the browser persists user data when using the default data_directory(), both in the default case, and in the case of a custom profile. I assume that we can hard-code platform-dependent paths manually to support this api.
• WebviewProfile::display() -> String returns the configured display name, "private", or "default" depending on the type of profile.
  • Should also implement std::fmt which should call the above function.

Adding WebviewProfile to WebContext

I propose the addition of a WebviewProfile field to be passed into and stored within WebContext (in addition to data_directory), with various platform-specific handlings of what to do with that profile. That should be sufficient to provide the above struct to Tauri and by extension to the end user as an additional parameter for each Webview.

Describe alternatives you've considered
I initially considered using the data_directory() api to emulate different profiles across all platforms, similar to what I proposed for the WebkitGTK polyfill. Unfortunately, as @FabianLars points out in Tauri#8637, that "We can't control the data dir on macos."

Additionally, Microsoft justifies the addition of multiple profiles (over the existing data folder api) as follows:

Previously, without multi-profile support, to achieve data separation, a WebView2 app could use different user data folders for different WebView2 controls. However, in that approach, you must run multiple WebView2 runtime instances (each including a browser process and a bunch of child processes), which consumed more system resources including memory, CPU footprint, and disk space. source

Additional context

This is an extension to my Tauri issue #9285, as @amrbashir suggested to first implement it here first.