I have an automatic test suite that uses Selenium to control a Chrome browser with a particular version. However Chrome tries to update itself between test runs. How do I prevent Chrome from automatically updating itself?
Removing write permission from the Google Chrome binary appears to prevent it from self-updating, at least on macOS.
In Python you can do that with code that looks like:
import subprocess
def remove_write_permissions(itempath: str) -> None:
subprocess.run([
'chmod',
'-R',
'a-w',
itempath
], check=True, capture_output=True)
remove_write_permissions('/Applications/Google Chrome.app')
I've only tested this code on macOS. It probably also works on Linux, but probably not Windows.
Related
I have a basic selenium script running/deployed on aws lambda.
Chrome and chromedriver and installed as layers (and available on /opt) via serverless.
The script works ... but only some of the time and rarely at scale (invoking more than 5 instances asynchronously).
I invoke the function in a simple for loop (up to about 200 iterations)
response = client.invoke(
FunctionName='arn:aws:lambda:us-east-1:12345667:function:selenium-lambda-dev-hello',
InvocationType='Event', #|'RequestResponse'|'Event' (async)| DryRun'
LogType='Tail',
#ClientContext='string',
Payload=event_payload,
#Qualifier='24'
)
Other runs, the process hangs while initiating the selenium driver on this line
driver = webdriver.Chrome('/opt/chromedriver_89', chrome_options=options)
other iterations the drivers fail/throw a 'timeout waiting for renderer exception'
This I believe is often due to a mismatch of chromedriver/chrome. I have checked and verified my versions are matched up and compatible (and like i said they do work sometimes).
I guess i'm looking for some ideas/direction to even begin to troubleshoot this. I was under the impression that each invokation of a lambda function is in a separate environment, so why would increasing the volume of invokations have any adverse effect on how well my script runs?
Any ideas or thoughts would be greatly appreciated all!
Discussed in the comments.
There's no complete solution but what has helped improve the situation was increasing the memory of the Lambda service.
The alternatives to try/consider:
Don't use Chrome. Use requests and lxml to query the pages via the network level and remove the need for Chrome.
I did something similar to support another stack question recently. You can see it's similar but not quite the same.
Go to a url and get some text from an xpath:
from lxml import html
import requests
import json
url = "https://nonfungible.com/market/history"
response = requests.get(url)
page = html.fromstring(response.content)
datastring = page.xpath('//script[#id="__NEXT_DATA__"]/text()')
Don't use Chrome. Chrome is ideal for functional testing - but if that's not you objective consider using HtmlUnitDriver or phantomjs. Both of these are significantly lighter than chrome and won't require a browser to be installed (you can run it straight from libraries)
You only need to change the driver initialisation and the rest of the script (in theory) should work.
PhantomJS:
$ pip install selenium
$ brew install phantomjs
from selenium import webdriver
driver = webdriver.PhantomJS()
Unit Driver:
from selenium import webdriver
driver = webdriver.Remote(
desired_capabilities=webdriver.DesiredCapabilities.HTMLUNIT)
I am using Selenium with Robot Framework to run an Electron application. The application is built to read a configuration file from the user data directory. As far as I understand, this is the location where this file should be stored.
The electron main process reads the configuration file:
const localConfigFile = path.join(app.getPath('userData'), 'config.json');
const localConfig = fs.existsSync(localConfigFile) ? require(localConfigFile) : {};
The built production version works just fine and reads the file as expected, but when starting it from Robot using SeleniumLibrary, the file is not read. This leads me to believe it's a problem with Robot, Selenium or ChromeDriver.
Robot creates the webdriver using SeleniumLibrary:
Create Webdriver Remote desired_capabilities=${starting_parameters} command_executor=http://127.0.0.1:9515
Where starting parameters are simply:
{ "chromeOptions": {"binary": <binary_location> }}
Chromedriver is started as a separate process from /usr/bin/chromedriver where it has been installed and uses the default port 9515.
The versions that I am using are:
ChromeDriver 2.36.540471 (9c759b81a907e70363c6312294d30b6ccccc2752)
"electron": "^6.0.2"
"electron-builder": "^21.2.0"
robotframework==3.2.1
robotframework-seleniumlibrary==3.3.1
Ubuntu 18.04.4 LTS
Experienced the same problem. Finally changing the Chromedriver's user-data-dir argument to Electron's userDataDir solved the problem.
options.add_argument('--user-data-dir=' + str(app_config_path()))
I found out the problem by using Spectron and logging the Electron main console. In general I would advice using Spectron instead of Robot to test Electron apps.
The issue is that the user data directory was not the same as the Electron default. When running the application through Chromedriver, the user data directory is changed to /tmp/somethingsomething so naturally the file under ~/.config/app-name was not found.
My solution was to use Electron'ss application data directory instead:
app.getPath('appData')
By default this is one directory up from the user data directory, but remains the same when running through Chromedriver.
I have write a few browser test who run with TestCafe, chrome:headless. The test are launched by commandline, from a server that I don't want to change the default language.
My website is multi-language. I want to be change the language of the test, without having to impact the language of the server/computer each time. How can I do that?
I launch the tests with this command line:
npx testcafe chrome:headless src/scenarios/**/*.test.ts
It all depends on your "multi-language" implementation:
Navigate to some "locale" page version (example.com/en/).
Start your tests from a landing page and then navigate to the specific "locale" version:
await t
.click(Selector('#choose-lang-combo')
.click(Selector('#en-lang'))
Try to add your own Accept-Language header to your request.
Use a custom user profile. Maybe just using the --lang flag (testcafe chrome --lang=es) will help you (without the custom user profile):
For example, to create a shortcut that launches Google Chrome in Spanish (es), you might create a shortcut named chrome-es that has the following target:path_to_chrome.exe --lang=es --user-data-dir=c:\chrome-profile-es
During the test, a file (.html) will be downloaded from the web application & I have to verify that file by opening it on the browser. In the non-headless mode, my test is working fine. But whenever I'm going to headless mode, that file is not getting downloaded to the download path (i.e. pointed in the "user.dir"). My chrome driver version is 2.44.609538 & selenium version is 3.14.
Apparently this could help you
Shawn Button post the answer related with it.
Downloading with chrome headless and selenium
Are you running the test from the command line?
Because, according to an answer to this question and this, when you run it via command line, your user.dir corresponds to your global user directory (C:\users\username).
This worked for our ruby implementation:
Capybara.register_driver :scrapping_driver do |app|
options = Selenium::WebDriver::Chrome::Options.new
options.add_argument('--headless')
options.add_argument('--disable-popup-blocking')
options.add_argument('--disable-gpu')
options.add_argument('--no-sandbox')
options.add_argument('--disable-dev-shm-usage')
options.add_argument('--window-size=1366,2000')
options.add_preference(:download, directory_upgrade: true,
prompt_for_download: false,
default_directory: "#{Rails.root}/")
options.add_preference(:browser, set_download_behavior: { behavior: 'allow' })
Selenium::WebDriver::Service.driver_path = Webdrivers::Chromedriver.driver_path
driver = Capybara::Selenium::Driver.new(app, browser: :chrome, options: options)
end
Pay attention at download behaviour
I met same situation.
Headless mode is very faster. So your code might be implemented to detect download(DL).
Solution.
(Current your process?) .click for DL -> Detecting download file generation.
(My solution) Detecting download file generation -> .click for DL.
I implemented the above mechanism using callback function.
I have an app that's designed to still be functional when JavaScript is disabled, so I wanted to write some specs that covered those cases.
I'm using Selenium (Firefox) with Capybara and I'm registering an new driver with JavaScript disabled (via Selenium's javascript.enabled property)
# spec/rails_helper.rb
Capybara.configure do |config|
config.ignore_hidden_elements = true
config.default_driver = :selenium
end
Capybara.register_driver :disable_js do |app|
profile = Selenium::WebDriver::Firefox::Profile.new
profile["javascript.enabled"] = false
Capybara::Selenium::Driver.new(app, profile: profile)
end
# spec/features/siging_in_spec.rb
context "JavaScript disabled", driver: :disable_js do
it "user can still sign in" do
# ...
# ...
end
end
The feature specs are failing to actually disable JavaScript. When the browser window pops up during testing and I pause it with binding.pry, I can definitely click around on items I know require JavaScript and see them working.
Side note: If I actually go to my Firefox settings and disable JavaScript, the test passes. So it appears it's inheriting whatever configuration I set in my browser, and not actually using the configuration specified when registering the driver.
Is this the correct approach here, or is there something I missed?
Thanks!
It's not possible to change the javascript.enabled setting when registering the driver because selenium freezes it at true - https://github.com/SeleniumHQ/selenium/blob/master/javascript/firefox-driver/webdriver.json#L35 - This was done because of issues with trying to use selenium and firefox with JS disabled https://github.com/SeleniumHQ/selenium/issues/635 - and is unlikely to be changed. Can you just run those specific tests with the rack_test driver? or does it not provide enough functionality?
Unfortunately, setting profile["javascript.enabled"] = false no longer works.
An alternative is to install a Firefox addon that disables JavaScript. This worked for me with Firefox 45 ESR, selenium-webdriver (2.53.4), and capybara (2.8.1):
profile.add_extension(File.expand_path('../quickjava-2.1.0-fx.xpi', __FILE__))
# Configure the extension to disable JavaScript by default.
profile['extensions.thatoneguydotnet.QuickJava.startupStatus.JavaScript'] = 2
# Disable loading the extension's first-run tab.
profile['extensions.thatoneguydotnet.QuickJava.curVersion'] = '2.1.0'
I evaluated a few different addons, including NoScript and QuickJs, but decided to find a very simple addon that could disable JavaScript by default—QuickJava did the trick. You can download the XPI file here (use Firefox, right click and Save As instead of installing directly): https://addons.mozilla.org/en-US/firefox/addon/quickjava/versions/
You can also see all of the addon's pref settings in the source.