JTAF-ExtWebDriver
JTAF-ExtWebDriver copied to clipboard
Firefox profile properties ignored if binary path property is default
In org.finra.jtaf.ewd.impl.DefaultSessionFactory.createInnerDriver(Map<String,String>,DesiredCapabilities), lines 376-405:
else if ((browser.equalsIgnoreCase("firefox") || browser.equalsIgnoreCase("*firefox"))) {
final String ffProfileFolder = properties.getFirefoxProfileFolder();
final String ffProfileFile = properties.getFirefoxProfileFile();
final String path = properties.getBinaryPath();
if (path != null) {
// Omitted: FirefoxBinary fireFox and FirefoxProfile ffp are created & configured
wd = new FirefoxDriver(fireFox, ffp, desiredCapabilities);
} else {
wd = new FirefoxDriver(desiredCapabilities);
}
}
If the binary path is null, the factory creates a default FirefoxDriver and ignores your profile config.
The old EWD didn't require an explicit binary path to use a profile - is this change intended, or shall I fix it?
Cool. We should have good tests around this so that we test this behavior as well as the other existing behaviors.
Thanks.
@knappk, do you think you can make a fix before 1.2 release?
@kood1 Yes I think so. The fix is easy, the uncertainty is in testing: I've not asked Firefox for its profile info before. I can't imagine the FF team will have made that too difficult though.
Dependency on Firefox may not be a good idea... At least we should check that we are able to exercise all the different ways to load up FF driver (clean, with profile, with binary path, etc).
Offhand I can't think of a way to test if the FF driver has correctly started up with a profile, without hitting FF itself... will mull it over
You may be able to read the FF config file and figure out your changes (e.g. default download location).
Any updates on this?
For testing, have we confirmed whether will we need browser-specific tests that leverage a feature from the profile, or can we do in a browser-agnostic way?
CCB feedback, We need to check if WebDriver supports calling profile without binary. @SMxJrz is saying that as of 2012, binary was indeed required for this, but maybe this has changed.
If binary is required, we should update this code to log a warning rather than ignoring silently. If not, we should remove the check for binary.
To answer my own question from earlier, we do not need Firefox-specific tests for this -- just a verification of warning(s) present.