I have a Windows 10 laptop running a Windows 7 Virtual Machine. Inside the Virtual Machine, when i start the WebDriver, it gives the error gpu_process_transport_factory.cc<1009> Lost UI shared context when it is started:
IWebDriver driver = new ChromeDriver() //This causes the 1009 Error
Also then varies for Failed to query stereo recording and Failed to send GpuChannelMsg_CreateCommandBuffer and command_buffer_proxy_impll.cc<115> Shared memory handle is not valid.
This has been working for months and no changes were made (this WebDriver is the sole purpose of the Virtual Machine), the laptop running it is running fine (ie. no GPU problems). The WebDriver still navigates through pages, but giving further errors and 10x slower.
EDIT: Updated to ChromeDriver to 2.35 and still the same behavior.
Headless Chrome was shipped in Chrome 59 by Google Team which introduced a way to run the Chrome Browser in a Headless Environment.
A note was added as :
Headless mode has been available on Mac and Linux since Chrome 59. Windows support came in Chrome 60.
The article Getting Started with Headless Chrome mentioned that :
--disable-gpu \ # Temporarily needed if running on Windows.
A note was added as :
Right now, you'll also want to include the --disable-gpu flag if you're running on Windows.
As per the discussion Headless: make --disable-gpu flag unnecessary it was clear that :
The --disable-gpu flag is no longer necessary on Linux or Mac OSX. It will also become unnecessary on Windows as soon as the bug SwiftShader fails an assert on Windows in headless mode is fixed.
What happened under the hood?
As per the discussion headless: Switch from osmesa to SwiftShader as Google/Chromium team decided to ship SwiftShader with Chrome, the team thought to start using it to render GL content in Headless Mode. This required a couple of changes as follows :
Skip GPU data collection in Headless Mode since SwiftShader isn't considered a software implementation by that code which lead to a failure when we tried to retrieve information from the Window System.
Only skip GL initialization in InitializeStaticEGLInternal if we intend to use osmesa. SwiftShader requires initialization like the other non-software implementations.
SwiftShader is currently not supported on Mac OSX, so the team decided to continue to use the physical GPU in Headless Mode on that platform (unlike on other platforms where everything is software rendered).
So, to disable WebGL support in Headless Mode they decided to use --disable-gpu and --disable-software-rasterizer
The idea to Support WebGL in headless is still under discussion but SwiftShader fails an assert on Windows in headless mode with an error as :
[0117/125830.649194:ERROR:gpu_process_transport_factory.cc(1043)] Lost UI shared context.
DevTools listening on ws://127.0.0.1:37429/devtools/browser/1f0b2bf7-dfdd-44ac-9da7-f2659d352f0d
Conclusion
This error doesn't impact your #Test and you can ignore the error for the time being.
This appears to be an issue with the latest version of Chrome (65.0.3325.146). By rolling back to an earlier version of Chrome (64.0.3282.186) the issue disappeared for me.
Will investigate further and update here if I find any more info but as a temporary workaround you can uninstall chrome and install version 64.0.3282.186.
'Lost UI Shared Context' was mistaken for an error while it's actually a logging output.
This has been fixed since Chrome 72.0. no extraneous arguments needed.
Related
I tried crawling a specific site using selenium and webdriver_manager.chrome, and my code crawled elements of that site totally. But after crawling, the following error message appears in the console window.
ERROR:gpu_init.cc(426) Passthrough is not supported, GL is disabled
When I first found it, I unchecked Hardware hardware accleration of chrome also it didn't solve the problem.
Tested environment
Windows OS, Chromedriver vesion 89, headless mode
Solution
I am not certain that this can be a solution for your question, since the error message is slightly different.
As I remember correctly, the error message Passthrough is not supported, GL is swiftshader has been shown after the Chromedriver version 89 as a bug (but not certain) [1].
In case of Windows, --headless and --disable-gpu options are required to make the chromedriver work as a headless mode [2]. It seems like --disable-gpu is also required for Linux because of the bug [3].
The error message does not appear if both --headless and --disable-gpu options are removed. However, the chromedriver does not work as a headless mode anymore.
In my case, the error message does not affect the operation of a headless chrome. As I found, "Normally, Chrome would just fall back to work without GPU. However, for consistent results, Telemetry requires the presence of GPU [4]."
I've additionally applied --disable-software-rasterizer option to disable WebGL [5]. The error message does not show anymore under the headless operation.
References
[1] https://reddit.com/r/chrome/comments/n6qywt/hardware_acceleration_fail_in_chrome_on_linux/
[2] https://developers.google.com/web/updates/2017/04/headless-chrome
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=737678
[4] https://groups.google.com/a/chromium.org/g/telemetry/c/bEgV1EH63eA
[5] https://bugs.chromium.org/p/chromium/issues/detail?id=617551
I had the same problem with selenium and chromedriver. For me the solution was to activate WebGL in Chrome browser. I did the following
chrome://settings -> Click Advanced at the bottom -> Check the Use hardware acceleration when available box
chrome://flags -> Search for WebGL in the search bar -> Enable / Activate WebGL
There are much better instructions here: https://superuser.com/questions/836832/how-can-i-enable-webgl-in-my-browser
I got this error as a result of using NVIDIA's Quadro view so for me the fix was to disable that.
I received this error during Eclipse Startup and fixed it by changing two things:
Now using a more recent Java VM for Eclipse, in my case I was moving from Java8 to Java11
Also moving from JRE to JDK
Add Eclipse Start Parameter:
-vm C:\PROGRA~1\ECLIPS~1\jdk-11.0.12.7-hotspot\bin\javaw.exe
This warning was being shown to me in a setup where chromium was running through Xvfb. I managed to get rid of this warning by adding the following flag to the command line:
--disable-features=DefaultPassthroughCommandDecoder
there should be typo mistake in your code , please check ,
i got the similar error in electron
[7608:1220/032708.152:ERROR:gpu_init.cc(523)] Passthrough is not supported, GL is disabled, ANGLE is
the problem was type mistake
before
wrong code
// events funstions of electron
SM_app.on('redy', F_create_windows);
fixed code
// events funstions of electron
SM_app.on('ready', F_create_windows);
i was missing a in my code. redy
Check Your Code. Again
My organization, just upgraded to Version 81.0.416.53 (Official build) (64-bit) of the edge chromium browser and I am the automation engineer for it. I am having issues getting my version of Watir/Ruby to work with it I have updated the Edge Webdriver to match the version number of the browser. I was originally using the Chrome class to interact with chromium, now that no longer works, but when I switch to Edge I keep getting a w3c error when I attempt to run my ui automation scripts. There doesn't appear to be a way for me to programatically turn off the Hardware acceleration for the webdriver through the Edge class in Watir/Selenium. I have turned it off for my browser, but when I run the webdriver, it is still turned on. Is there any way for me to make this change directly in the webdriver instead of trying to change an option that doesn't exist in Watir?
I am open to other suggestions if you have them. Thank You for your time.
System:
ruby 2.5.8p224 (2020-03-31 revision 67882) [x64-mingw32]
watir(6.16.5)
selenium-webdriver (3.142.7)
Edge Chromium Version 81.0.416.53 (Official build) (64-bit)
Windows 10
Code:
require 'watir'
Selenium::WebDriver::Edge::Service.driver_path = "c:/webdriver_location/msedgedriver.exe"
client = :edge
browser = Watir::Browser.new(client)
I ran into a similar issue before. You could use the options like Chrome's in Edge Chromium. The code in ruby is like the following:
capabilities = { "edgeOptions" => {'w3c' => false} }
I'm not familiar with Watir, don't know if this syntax can be used in Watir. You could change it into the usable one in Watir.
For more detailed information, you could also refer to this thread.
I am facing a very slow response when running my scripts on IE11. Sometimes, I get FocusWindowsClosed, ElementIsNotClickable. I have changed the zoom settings for all zones, created feature BFCACHE for IE in feature control, added capabilities into my code but nothing works for me. If anyone has any idea why I am facing this issue. Do i need to downgrade window or IE versions? I have also downloaded the same version of selenium client server with same IEDriver which is (3.8.0).
To start with, Selenium v3.8.0 of 2017-11-30 is more then 2 years older. Even the error trace logs would be difficult to debug. So as per best practices you may like to:
First of all, the fact that ...64-bit IEDriverServer executable populate the input fields with the character sequence very slowly as compared to 32-bit IEDriverServer executable.... is a known issue.
You can find a detailed discussion in IEDriverServer sends text very slowly using Selenium to the search field
Ensure the Internet Explorer Protective mode setting are properly configured.
Ensure the Zoom level is properly configured.
Ensure ignoreProtectedModeSettings is properly confugured.
Ensure setting up selenium to work with internet explorer.
Ensure FEATURE_BFCACHE is properly confugured.
Upgrade Selenium to current levels Version 3.141.59.
Upgrade IEDriverServer to latest IEDriverServer v3.150.1 level.
Note: As per best practices as Selenium Client and InternetExplorerDriver are released in sync and you must try to use both the binaries from the same major release.
Clean your Project Workspace through your IDE and Rebuild your project with required dependencies only.
Execute your #Test.
Always invoke driver.quit() within tearDown(){} method to close & destroy the WebDriver and Web Client instances gracefully.
tl;dr
A couple of references:
Internet Explorer 11 getting stuck randomly while executing tests through IEDriverServer and Selenium
HTTP Status: '500' -> incorrect JSON status mapping for 'timeout' (408 expected) while clicking element with IEDriverServer Selenium and Java
Environment:
selenium-server-standalone-3.8.1.jar
geckodriver-v0.24.0
firefox 60.6.1
Everything was set up 6 months ago and everything worked well, the tests passed through the Selenium and there were no problems.
Since 08/23/2019 problems began. Without any launches test inside the Selenium process, started to run spontaneously browsers (firefox) and did not turn off.
These processes overload the processor on the server, after which the server starts to brake and also the site that is on the server. These "browser launches" continue until Selenium is reloaded by open browsers after which our automatic tests are blocked and display an error: "unable to create new native thread".
As soon as one such browser spontaneously opens, the processor load becomes 100%.
These browser launches occur approximately 1 time in 4-5 minutes.
All tests are disabled, but Selenium lives its own life, and continues to launch the browsers.
Maybe someone faced a similar problem? Any ideas why this is happening and how to fix it?
The launch of selenium occurs on command:
su screener -c "/usr/bin/java -Dwebdriver.gecko.driver=/usr/local/bin/geckodriver -jar /usr/lib/selenium/selenium-server-standalone-3.8.1.jar -enablePassThrough false -port 4444 >/var/log/selenium/selenium_std.log 2>/var/log/selenium/selenium_error.log &"
Term yourself lucky to have sailed smoothly with geckodriver-v0.24.0 and selenium-server-standalone-3.8.1.jar till 08/23/2019.
As per the documentation:
To work with geckodriver-v0.24.0 you need:
Selenium Python client version greater then 3.14
Firefox client version minimum 57 (which seems to be okay)
You can find the detailed GeckoDriver, Selenium and Firefox Browser compatibility chart in the discussion Which Firefox browser versions supported for given Geckodriver version?
Additional considerations
As a part of the best practices:
Upgrade JDK to recent levels JDK 8u222.
Upgrade Selenium to current levels Version 3.141.59.
Upgrade GeckoDriver to GeckoDriver v0.24.0 level.
GeckoDriver is present in the desired location.
GeckoDriver is having executable permission for non-root users.
Upgrade Firefox version to Firefox v65.0.2 levels.
Clean your Project Workspace through your IDE and Rebuild your project with required dependencies only.
http://www.yourownlinux.com/2013/10/how-to-free-up-release-unused-cached-memory-in-linux.html) before and after the execution of your Test Suite.
If your base Web Client version is too old, then uninstall it through Revo Uninstaller and install a recent GA and released version of Web Client.
Take a System Reboot.
Execute your Test as a non-root user.
Always invoke driver.quit() within tearDown(){} method to close & destroy the WebDriver and Web Client instances gracefully.
You can find a detailed discussion in PhantomJS web driver stays in memory
If the stale WebDriver instances still persist you may require to forcefully remove them.
You can find a detailed discussion in Selenium : How to stop geckodriver process impacting PC memory, without calling driver.quit()?
Outro
Limit chrome headless CPU and memory usage
Using headless chrome and selenium I can succesfully send keys to websites on my Mac. When I port the same code to my Linux machine it crashes however. The offending line is the following one:
driver.find_element_by_xpath('//input[#id="username"]').send_keys(username)
And I get the following error message:
"an X display is required for keycode conversions, consider using Xvfb"
Why is this not working on Linux?
This is a bug in chromedriver that is detailed here.
According to the new lead for chrome driver
The issue is in ChromeDriver. As its name implies, the sendKey command sends simulated key strokes to Chrome, and ChromeDriver is responsible for converting the input text string into corresponding keystrokes to send to Chrome. On Linux, ChromeDriver uses X display to do the conversion, and fails when no X display is available.
It has been fixed recently and will be released in v 2.31. Unfortunately the chromium team does not make nightly builds publicly available and there is no official release date yet.
In the meantime you can build your own chromedriver or download a prebuilt binary from a third party... Both a dockerfile and a working binary may be found at this github.