Allow existing user profile to be used

[zackw]

Firefox Version

52.0esr

Platform

x86_64-linux

Steps to reproduce -

I'm trying to update a complicated program that drives Firefox via Selenium (Python bindings) to Selenium 3.3, which means geckodriver is now used under the hood.

In Selenium 2.x, if you created a FirefoxProfile object, its path property told you the directory that would actually be used as the Firefox profile directory. The complicated program relies on this: it wants to be able to communicate with an extension by reading files out of the profile directory, and it also wants to be able to save things like the cookie jar after puppeting Firefox for a while.

In 3.x, geckodriver copies the profile dir on startup, and I am not having any luck finding a way to learn the name of the directory that is actually being used by the Firefox instance.

Can we please have a mode in which geckodriver is given the directory to use as the profile, and does not copy it, delete it, nor indeed tamper with it more than absolutely necessary? And can we please get that plumbed into official Selenium so that existing code that expects to be able to see the profile directory Just Works again?

... And in the meantime, is there any way to learn the name of the actually-in-use profile directory via the Selenium bindings? I will parse geckodriver.log if I really have to, but I'm hoping there's something better.

[andreastt]

The profile is being read in as a Base64-string to the capabilities object because the local- and remote ends might not live on the same system. If you give the profile as a path on the local system, it might not exist on the remote system where geckodriver actually runs.

I guess it might be possible to somehow make geckodriver pick up the profile directory from the local system if a path is provided, e.g. if the geckodriver instance is running on the same system as the script, but the path of the copied profile is retrievable by looking at the moz:profile capability that is returned.

After starting a session, a JSON response like this is returned:

{"moz:profile": "/path/to/real/profile", …}

[zackw]

The profile is being read in as a Base64-string to the capabilities object because the local- and remote ends might not live on the same system. If you give the profile as a path on the local system, it might not exist on the remote system where geckodriver actually runs.

It is fine with me if this only works when geckodriver, Firefox, and the program using geckodriver are all running on the same computer; I have to do it that way anyway, for unrelated reasons.

[andreastt]

I sketched out a proposal for how to define paths to existing profiles in #571 (comment). We should indeed take care that existing profiles are not deleted when geckodriver exits.

[whimboo]

So this works already by using args of Firefox Options: https://github.com/mozilla/geckodriver/#mozfirefoxoptions

To have geckodriver pick up an existing profile on the filesystem, you may pass ["-profile", "/path/to/profile"].

But please note that there is still issue #1058 open.

[zackw]

With #299 in mind, if you do that, will the existing profile survive after `driver.quit()`?

[aronaks]

Steps to reproduce:

1. Get a driver
2. Save a value from driver.capabilities[moz:profile] to a variable, e.g.
   path_to_profile='/var/folders/l4/qd_syjy16v38vxgsh551xzxmckxnb7/T/rust_mozprofile.wwLbOvL7RW9D'
3. Call driver.close() or driver.quit()

Expected result: Check that the path to profile exists
Actual result: moz:profile's path has been removed after calling driver.close()

OSError: [Errno 2] No such file or directory: '/var/folders/l4/qd_syjy16v38vxgsh551xzxmckxnb7/T/rust_mozprofile.wwLbOvL7RW9D'

how can let geckodriver know that i need that profile after calling 'driver.close()' so that it won't delete it?

[whimboo]

It's a temporary profile which always gets removed once the tests have been finished. You want to use a custom profile then.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you have run into an issue you think is related, please open a new issue.