I was trying to test if Chromium on Linux is accessing the webcam correctly via the headless mode:
chromium-browser --headless https://example.com --repl
But chrome seemed to be ignoring video capturing device input, since the the webcam indicator LED was not lighting up. However, the same test page worked just fine when Chrome was running in GUI mode.
Here is the output prompt before the REPL line:
[0512/233001.068247:ERROR:gpu_process_transport_factory.cc(1019)] Lost UI shared context.
[0512/233002.458966:ERROR:video_capture_device_factory_linux.cc(102)] Not implemented reached in std::list media::(anonymous namespace)::GetFrameRateList(int, uint32_t, uint32_t, uint32_t)
[0512/233002.459566:INFO:headless_shell.cc(399)] Type a Javascript expression to evaluate or "quit" to exit.
Is this a limitation of the headless mode of Chrome?
Do you really need to use webcam? If not, then you can use fake cam?
If so, then try:
chrome.exe --use-fake-ui-for-media-stream --disable-web-security --use-fake-device-for-media-stream --use-file-for-fake-video-capture="C:\Users\user\Desktop\test\fileName.y4m" --allow-file-access
Using this way you can test webcam in chrome.
Related
I'm trying to capture a screenshot of a minimized chromium window with https://www.codeproject.com/Articles/20651/Capturing-Minimized-Window-A-Kid-s-Trick. But all chromium based browsers end up as black and won't show. It works for all other windows like notepad and it works.
But when I try on a chromium based browser I get results like this.
I believe the issue is that it renders differently and i tried disabling gpu and direct x with arguments but it still didn't work.
cmd.exe /c start chrome.exe --no-sandbox --allow-no-sandbox-job --disable-3d-apis --disable-gpu --disable-d3d11 --user-data-dir=
Please do not respond with a method that brings the window to front then minimizes it again, thanks.
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.
When I execute tests using MicrosoftWebDriver for Edge all works fine, but when I minimise the window all tests become failed. Does Edge or MicrosoftWebDriver have any options to avoid that behavior?
As you have been trying to minimise the Browser Window while your Test Execution is In Progress it will be against all the Best Practices. At this point it is worth to mention that as Selenium mocks the User Actions hence Selenium needs Browser focus. If the focus is lost Selenium won't be able to execute the lines of code. Consider the following steps while your Test Execution :
Browser Maximize : While you execute your tests always keep the Web Browser maximized so majority of the elements are within the Viewport
As per best practices, you should try to execute your Test Scripts / Automation Framework in an isolated Test Environment away from Manual Intervention with all the required Software and Hardware configurations and setup.
You can find a detailed discussion in How to run chrome driver in background using selenium with Ruby for Mac OSx?
You also have an option to use Google Chrome or Mozilla Firefox in Headless version.
For Firefox you can find a detailed discussion in How to make firefox headless programatically in Selenium with python?
For Chrome you can find a detailed discussion in selenium.common.exceptions.WebDriverException: Message: 'chromedriver' executable needs to be in PATH error with Headless Chrome
For Ghost Browser you can find a detailed discussion in Which drivers support “no-browser”/“headless” testing?
When running tests, I would like not to be bothered by Chrome popping-up every time Behat launches a scenario needing Chrome.
I know there is a maximizeWindow() method for session objects, but nothing like "minimize".
Nowadays, you can set Chrome to run in headless mode like so (behat.yml):
default:
extensions:
Behat\MinkExtension:
javascript_session: browser
sessions:
browser:
selenium2:
browser: chrome
capabilities:
chrome:
switches:
- "--headless"
You could run Chrome with a virtual framebuffer, so that the window appears on a virtual screen instead of your real screen.
This also allows to easily run your tests on a headless machine, such as a build server.
On Linux, we're using xvfb for this particular purpose. More info: How To Run Your Tests Headlessly with Xvfb
For Windows, see Is there anything like xvfb or xnest for Windows?
Seems there is no method for launching in background. maximizeWindow is for setting the resolution.
You should try to run in a virtual machine or on another PC in order to avoid this kind of issues, popups and interacting by mistake with the window that runs automation.
Running on the same machine should be done when writing new tests and when debugging.
I found an acceptable solution for this that didn't require me to run Chrome headless or in a virtual machine.
Simply log in with a secondary user account on your local machine, and run selenium on that account. Then, switch back to your main user account and run your tests. The chrome browser will be created under the user running selenium and you will never see the chrome windows pop up.
Is there a way to use phantomjs to drive my firefox/chrome browser?
We have a bunch of casperjs tests, that I would like to run directly in the browser for debugging ( or just pure interrest ).
I seem to recall that a long time ago, before phantomjs became pure headless, I could do this by making it run on X instead of xvfb and removing/uncommenting the phantom.exit() line.
PhantomJs IS a browser, so the answer is no. You may want to look into Karma however.
You just use a config file which allows you to provide a browser to run your tests in:
Chrome
ChromeCanary
Firefox
Opera
Safari (only Mac)
PhantomJS
IE & Edge (only Windows)
SauseLabs, BrowserStack Electron, & more
Still, your tests will need to be written in QUnit, Jasmine, Mocha, ... which can be too much work to port from CasperJs.