Why does Selenium always create temporary Firefox profiles using the Web Driver?

Why does Selenium always create temporary Firefox profiles using the Web Driver, although I told him to use the existing one?

According to this answer, it is impossible to stop Selenium from creating temporary Firefox profiles using the Web Driver. But with a chronograph, I can achieve this. So why is it different from Firefox. I checked the FirefoxProfile.cs Selenium repo and found that the following snipet code is used to copy the 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 are no such things.

This is because webdriver installs the extension (webdriver.xpi) to communicate with firefox, while chromedriver.exe is used to interact with chrome.

If so, in version 3.0 webdriver uses geckodriver.exe to communicate with firefox. So, after version 3.0 will webdriver now create a temporary profile for firefox?

Update: Today I played with webdriver v 3.0+ and found that the latest version with legacymode disabled still creates a temporary profile called rust_mozprofile.wUqPXh48avDR . My assumption is that this temporary profile is generated by geckodriver.exe , which is written in Rust

I used chromedriver 3 years ago and am not sure that chromedriver.exe also generates this type of temporary file. Waiting for a response from experts ...

0
firefox selenium webdriver selenium-chromedriver geckodriver
Nov 10 '16 at 7:04
source share
1 answer

The main reason the Firefox driver uses a temporary profile is to support the option of using multiple independent concurrent Firefox instances. Once, when Firefox started, it would lose the control or blocking file in the profile directory and detect this file if the user tried to start a new instance of Firefox, not allowing them to do this. Regardless of whether this behavior demonstrates Firefox, the driver should still work with some older versions of the browser and should take it into account. Selenium's solution to solving this problem with WebDriver, when a user wants to use a specific profile, is to copy the contents of this profile to a new directory and launch Firefox, pointing to the copy.

It seems that the Mozilla implementation does basically the same thing. I would suggest that for the same reason - to support the use of multiple instances.

+1
Nov 10 '16 at 12:31 on
source share
— -



All Articles