Why Selenium always create temporary Firefox Profiles using Web Driver?

Question

Why Selenium always create temporary Firefox Profiles using Web Driver though I told it to use a existing one ?

According to this answer it is not possible to stop Selenium from creating temporary Firefox Profiles using Web Driver. But with chromedriver I can achieve this. So why it is different for Firefox. I checked the FirefoxProfile.cs of Selenium repo and found the following code snipet is used to copy profile---

public void WriteToDisk()
    {
        this.profileDir = GenerateProfileDirectoryName();
        if (!string.IsNullOrEmpty(this.sourceProfileDir))
        {
            FileUtilities.CopyDirectory(this.sourceProfileDir, this.profileDir);
        }
        else
        {
            Directory.CreateDirectory(this.profileDir);
        }

        this.InstallExtensions();
        this.DeleteLockFiles();
        this.DeleteExtensionsCache();
        this.UpdateUserPreferences();
    }

But for chorme there is no such things.

Is it because webdriver install an extension (webdriver.xpi) to communicate with firefox whereas chromedriver.exe is used to interact with chrome.

If that is the reason, in version 3.0 webdriver is using geckodriver.exe to communicate with firefox. So after version 3.0 webdriver will create temporary profile for firefox any more ?

Update: Today I played with webdriver v 3.0+ and found that latest version with legacymode off is still generating temporary profile named as rust_mozprofile.wUqPXh48avDR. My assumption is this temporary profile is generated by geckodriver.exe which is written in Rust

I have used chromedriver 3 years back and not sure chromedriver.exe also generates such type of temporary file. Expecting answer from experts...

Answer 1

The main reason that the Firefox driver uses a temporary profile is to support the use case of running multiple independent simultaneous instances of Firefox. At one time, when Firefox launched, it would drop a sentinel or lock file in the profile directory, and would detect that file if the user attempted to start a new instance of Firefox, preventing them from doing so. Whether or not Firefox still exhibits this behavior, the driver still has to work with some older versions of the browser, and has to account for it. The Selenium project's solution to that issue with WebDriver, when a user wants to use a specific profile, is to copy the contents of that profile to a new directory, and launch Firefox pointing to the copy.

It sounds like Mozilla's implementation does largely the same thing. I would guess it's for the same reason - to support the multiple-instance use case.