Closed speilow-navi closed 10 years ago
Yes I can see the need for this. Unfortunately I think the various web driver teams have all stated to diverge and it's going to mean our open browser functionality will have to take it a separate parameter for every web driver type. i.e. ChromOptions, Firefox Profile, PhantomJS cmd line args, etc... etc...
I don't think we have any other choice but to do that. As this will also be needed for #215 #90 #204 #208 and probably a couple of others. So I think we should go ahead and do it. But at the same time we should all bitch and complain to the Selenium team for creating this mess int he first place...
OK I've also raised an associated issue with the core Selenium Team.
https://code.google.com/p/selenium/issues/detail?id=6026
Please up vote the issue so hopefully it gets some love.
@j1z0 I have thought a lot about this and do not like any solution I come up with. Maybe we should add an extra_arguments argument to open browser that is just a kwarg pass-through. I like how the Java bindings for PhantomJS use the DesiredCapability phantomjs.cli.args, but I think that is the only WebDriver to do that :(
@speilow-navi Until there are changes, you can put your manually constructed browser into the cache by adding code like this to your existing keyword:
from robot.libraries.BuiltIn import BuiltIn
...
s2l = BuiltIn().get_library_instance('Selenium2Library')
logger.debug('Opened browser with session id %s'
% driver.session_id)
return s2l._cache.register(driver, alias)
A full example can be found on the user group.
I like how the Java bindings for PhantomJS use the DesiredCapability phantomjs.cli.args, but I think that is the only WebDriver to do that :(
@ombre42 I've just suggested to the selenium team that they add basically this functionality for all webdrivers. If they say it's OK I'll go ahead and implement it and send the pull request and then we won't need to do anything on the S2L side as it will be fixed upstream.
Otherwise we implement the desired_capabilities parsing in S2L or as you suggested the extra_arguments argument is also a good way to go. Let's see what the selenium team says first and then take it from there.
Thanks all for the quick replys. ombre42, thanks for that code for the cache, that should allow us to get our tests working for the time being!
With newly implemented keyword 'Create Webdriver' you should be able to accomplish this with some lines like
*** Settings ***
Library Collections
Library Selenium2Library
*** Test Cases ***
Set Language In Chrome Using Create WebDriver Keyword
[Tags] chrome
${options}= Evaluate sys.modules['selenium.webdriver'].ChromeOptions() sys, selenium.webdriver
${langs}= Create Dictionary intl.accept_languages en_US,en_GB,en,de_DE,de,*
${options._experimental_options['prefs']}= Set Variable ${langs}
${options.add_argument}= Set Variable user-data-dir=/Users/SPeilow/AppData/Local/Google/Chrome/User Data/
Create WebDriver Chrome chrome_options=${options}
Close Browser
If you want to change the userdata config ,you need to do like below in windows:
*** Settings ***
Library Collections
Library Selenium2Library
*** Test Cases ***
Set Language In Chrome Using Create WebDriver Keyword
[Tags] chrome
${options}= Evaluate sys.modules['selenium.webdriver'].ChromeOptions() sys, selenium.webdriver
${options.add_argument}= Set Variable user-data-dir\=c:\\Users\\Jack\\AppData\\Local\\Google\\Chrome\\User Da\\
Create WebDriver Chrome chrome_options=${options}
Close Browser
While attempting to write some tests regarding the correct population of text fields as part of some internationalization testing, we encountered some difficulty in setting the language preferences in Google Chrome.
We have written our own keyword that allows us to specify the Chrome Options, enabling us to select the language and the user-data-directory, however as this is happening outside BrowserManagement we are then unable to interface with the browser after that, as it is not added to the common browser cache.
Our proposed solution would be to change the Open Browser keyword to accept a Chrome Options argument, or a Chrome user-data-directory (similar to the way that it currently supports firefox profiles).
Below is the keyword we have implemented, as an example of what we are trying to achieve.