That at least makes it possible to work around the issue relatively easily. Allow specifying the profile directory as a geckodriver command line argument.Improve the error message when we can't write to the profile dir.I don't know a lot about snaps, but it seems like there must be some way to allow launching a child process, otherwise almost nothing would work.Īltogether the short term fix here is probably: So packaging geckodriver and Firefox together makes less sense than it does for Chrome (we don't want to have to ship a new geckodriver release for every Firefox release, even when there are no geckodriver changes).īecause geckodriver tries to execute the firefox binary itself, and because this capability is denied by the strict confinement that's inherent to snaps, it wasn't working. The chromium snap that Ubuntu provides does itself package chromedriver (don't know if this happens for similar reasons) which is somewhat convenient since manually providing and keeping the chrome-/geckodriver in sync with the browser version is a little bothersome too.Ĭhromedriver has a 1:1 relationship with a specific version of Chrome, whereas geckodriver is expected to work across multiple Firefox releases. Yes, geckodriver needs to be able to set prefs in the profile, so they are avaiable at Firefox startup, and (more avoidably) needs to read the MarionetteActivePort file from the profile so that it can work out which port to connect to.

I'm not sure whether geckodriver wants control over that directory, to read/write things there too?

Mozilla geckodriver python