v126.x (Chrome bootstrap) unable to load cookies from prior version (Alloy bootstrap)

[EamonHetherton]

Is there an existing issue for this?

• [X] I have searched both open/closed issues, no issue already exists.

CefSharp Version

126.2.70

Operating System

Windows 11

Architecture

x64

.Net Version

net 8.0

Implementation

WinForms

Reproduction Steps

1. Initialize CEF with a clean CachePath on a prior version of CefSharp.WinForms.NETCore (e.g. I have tested various versions from 100.0.140-125.0.210) and either create a cookie manually or visit a site that sets a cookie.
2. update to 126.2.70 and using the same CachePath the cookie is no longer available.

Expected behavior

I would have expected that the cookie created in a prior version to still be available. I have just tested the process of upgrading the following versions and each time the cookies were still intact in the next version until I hit v126.2.70.

• 100.0.140 -> 119.1.20
• 119.1.20 -> 120.1.80
• 120.1.80 -> 123.0.60
• 123.0.60 -> 124.3.80
• 124.3.80 -> 125.0.210
• 125.0.210 -> 126.2.70 *no cookies

Actual behavior

no cookies appear to be in the cookie store immediately after upgrading to v126.2.70

Regression?

yes this looks like it worked in prior versions. it appears at least since 100.0.140 the cookies have been forward compatible until we reached v126.2.70

[amaitland]

Thanks for the detailed testing 👍 It's important to remember that CefSharp is just a wrapper around the Chromium Embedded Framework(CEF).

Try switching back to the Alloy bootstrap to see if that makes a difference. Refer to https://github.com/cefsharp/CefSharp/issues/4835#issuecomment-2183620313

Ultimately this will need to be raised at https://github.com/chromiumembedded/cef/issues

[EamonHetherton]

Thanks for the prompt reply, settings.ChromeRuntime = false; does appear to fix the issue with cookies still being loadable after the update. I'll try to dig deeper into the root cause.

[EugeneSunrise]

Thanks for the prompt reply, settings.ChromeRuntime = false; does appear to fix the issue with cookies still being loadable after the update. I'll try to dig deeper into the root cause.

I had a similar problem, the point is that when we use chrome bootstrap(ChromeRuntume = true, since 125 ver.) cookies are encrypted with a key that is stored in the Local State file, but if we use alloy bootstrap cookies are encrypted with a key from LocalPrefs.json

[amaitland]

Thanks for the prompt reply, settings.ChromeRuntime = false; does appear to fix the issue with cookies still being loadable after the update. I'll try to dig deeper into the root cause.

Please raise an issue on the https://github.com/chromiumembedded/cef/issues (post a link back here for reference).

We'll need to see if CEF can handle this case gracefully.

[EamonHetherton]

https://github.com/chromiumembedded/cef/issues/3721

[EamonHetherton]

We don't plan to migrate cache directories automatically https://github.com/chromiumembedded/cef/issues/3721#issuecomment-2187539681 :(

I thought about trying to auto detect the first run with the Chrome bootstrap and initialise the Alloy bootstrap first and extract all the cookies, then load Chrome bootstrap and insert the cookies but can only initialise CEF once per process so that becomes significantly more difficult

[EamonHetherton]

some success: https://github.com/chromiumembedded/cef/issues/3721#issuecomment-2187818342

Still not sure what to use to detect "first run" of Chrome bootstrap (probably the existence of LocalPrefs.json and not Local State file at this stage), but I think following the steps outlined in that link might work for me. Will also need to consider what other files/folders should be cleaned up as part of the Alloy->Chrome bootstrap migration.

Any thoughts on what else may need migrating?

[EamonHetherton]

Work in progress migration, works for me YMMV :)

public static class Alloy_To_Chrome_Migration
{
    private static readonly string[] FoldersToMigrate = ["Cache", "Code Cache", "DawnGraphiteCache", "DawnWebGPUCache", "GPUCache", "Local Storage", "Network", "Session Storage", "Shared Dictionary"];
    private static readonly string[] FilesToMigrate = ["LOCK", "LOG", "Visited Links"];
    private const string AlloyStateFilename = "LocalPrefs.json";
    private const string ChromeStateFileName = "Local State";
    public static void Execute(CefSettings settings)
    {
        var cache_path = settings.CachePath;
        try
        {
            string alloyStateFile = Path.Combine(cache_path, AlloyStateFilename);
            string chromeStateFile = Path.Combine(cache_path, ChromeStateFileName);
            if (settings.ChromeRuntime && File.Exists(alloyStateFile) && !File.Exists(chromeStateFile))
            {
                File.Move(alloyStateFile, chromeStateFile);

                var defaultDir = Path.Combine(cache_path, "Default");
                Directory.CreateDirectory(defaultDir);

                foreach (var migrationFolderName in FoldersToMigrate)
                {
                    var migrationFolder = Path.Combine(cache_path, migrationFolderName);
                    if (Directory.Exists(migrationFolder))
                    {
                        Directory.Move(migrationFolder, Path.Combine(defaultDir, migrationFolderName));
                    }
                }
                foreach (var migrationFileName in FilesToMigrate)
                {
                    var migrationFile = Path.Combine(cache_path, migrationFileName);
                    if (File.Exists(migrationFile))
                    {
                        File.Move(migrationFile, Path.Combine(defaultDir, migrationFileName));
                    }
                }
            }
        }
        catch (Exception)
        {
        }
    }
}

[amaitland]

We don't plan to migrate cache directories automatically. CEF doesn't know what Profile-specific directory you were using previously, and not all files/directories are applicable between Chrome and Alloy bootstraps.

https://github.com/chromiumembedded/cef/issues/3721#issuecomment-2187539681

As CEF isn't going to support automatic migration, it'll be up to users to manually migrate if required.