Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Sadly, Firefox Profiles are transmitted by wire from the hub to the node, that's why you have poor request timing. We've had the same exact problem and had to patch FirefoxDriver.</p> <p>In <a href="https://code.google.com/p/selenium/source/browse/java/client/src/org/openqa/selenium/firefox/FirefoxDriver.java?name=selenium-2.32.0" rel="nofollow">FirefoxDriver sources</a>, there is a method called <code>extractProfile</code> that check for the <code>desiredCapabilities</code> ' <code>firefox_profile</code> key then <code>requiredCapabilities</code> <code>firefox_profile</code> key to know which profile to load. If you add a profile through the client, it's sent by wire as a huge base64 String and decoded here.</p> <p>We've patched this part to handle "paths string" like /path/to/firefox to point to a local profile on node's filesystem. That's not difficult, but you'll have to maintain that.</p> <p>Maybe you could ask Selenium team to modify this part, we've haven't take the "bug report time" yet (as we thought this hack was due to our lack of knowledge of webdriver)</p> <p>You might be able to define the correct profile by modifiyng requiredCapabilities of existing Drivers. It's possibily a configuration thing, but we haven't found a well documented way to do it.</p> <p>While you stuck to wire transfer, profile transfer and decoding will slow down the entire process (20MB or so of base64 encoded string at each request would slow down Google's web servers too, I think ;-) )</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload