Using testcafe to test the front end of an Angular Web Application.
The front end uses stomp.js to check whether there is a Websocket connection. If there is no connection, the console will output a 'WebSocket connection to 'ws://localhost:8103/websocket' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED'.
We start a connector process with a batch file and let it run, when we stop the running connector process, the front end displays a message that the connection is lost. (Expected behavior with manual testing)
But whenever we use Testcafe to test the exact same scenario, we don't see the connection lost message. And we also don't see the Websocket connection failed error in the console of the tescafe execution browser. Unless we manually refresh the page in the browser that Testcafe started. Then we will start to see the Websocket connection failed error. It seems that when Testcafe starts a browser, the application is unable to use stomp.js to check whether there is a Websocket connection.
Browser used is Google Chrome version 84.04147.125;
Testcafe version: 1.8.8;
Stomp.js version: 7.2.0;
OS: Windows 10;
Could this be a Testcafe bug?
Related
I can no longer use DevTools remote debugging port api calls from a chrome driver instance that was started by selenium + chromedriver.
Previously we could use the dev-tools port using chrome-remote-interface.
Now, when I use chrome-remote-interface, the selenium webdriver seems to be unusable.
So for example, let's say I:
driver = new ChromeDriver()
Then I do this to go to a site:
driver.get("https://some-site.com")
So far so good.
Then I use the remote-debugging-port to make request as well.
See: https://github.com/cyrus-and/chrome-remote-interface for an example.
This also works.
Now I try to use the Java web driver again:
driver.get("https://some-site.com")
And I get an error:
[1651087065.452][INFO]: Done waiting for pending navigations. Status: timeout: Timed out receiving message from renderer: 0.000
[1651087065.452][INFO]: [4ac1553138574d061b37a45836c35096] RESPONSE GetCookies ERROR timeout: Timed out receiving message from renderer: 0.000
(Session info: chrome=100.0.4896.127)
[126480:126508:0427/141746.195721:ERROR:cast_crl.cc(391)] CRL - Verification failed.
I created an issue tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=1320455&q=reporter%3Ame&can=2
Does anyone know a solution to this?
You no longer need to use chrome-remote-interface to access the chrome debugging port. You can now use Selenium 4's new ChromeDriver dev tools SDK to execute commands against chrome through the CDP.
Switching to this fixed the problem.
So the concept is like this -
I would like to run the selenium server .jar file on a remote windows machine.
Then connect to it via the default port (:4444), open browser and navigate to a URL of my choosing.
I have everything working except the part of running the selenium server through robot.
This keyword works as far as I can tell (until the open browser keyword) -
Start Selenium Server
&{client} = Return Internal Host
Connect Environment Machine Windows ${client}
start process java -jar ${/}SeleniumServer${/}selenium-server-standalone-3.141.59.jar alias=seleniumserver
process should be running seleniumserver
open browser http://example.com/example.html chrome None http://1.1.1.1:4444/wd/hub
BUT, when I try to connect to the selenium server I get the following error -
"No connection could be made because the target machine actively refused it"
It seems like the process either does not run or runs for a short amount of time then closes.
What am I missing here?
If I manually start the server on the client, everything works. It opens the browser and does whatever I need. (manually running the java -jar selenium*.jar on the cmd)
But when I run this Start process keyword, that should keep the process running in the background, I get connection refused. Any Ideas?
Another piece of information that might be useful - The selenium server should throw an error if trying to run it twice on the same machine (because of the used port bind 4444).
When running the keyword shown above, while there is a selenium server up and running on the target machine, the test still passes for some reason. Not sure if it is even running the process as intended but the "process should be running" keyword seems to pass.
Thanks!
Im running chrome headless through chromedriver and selenium via python.
I've run into the following issue both on Mac and Linux.
Im starting chrome as follows:
if self.headless:
options.headless = True
options.add_argument("--headless")
if self.debug_port:
logging.info(f"Setting up remote debugging on port {self.debug_port}")
options.add_argument(f"--remote-debugging-port={self.debug_port}")
options.add_argument(f"--remote-debugging-address=0.0.0.0")
If I connect to http://localhost:9222 from another headed instance of chrome I can see the list of sessions and connect to it seamlessly. At which point i have a window opened up with a screencast of the remote session and the dev console.
Here's that successful example:
When I connect to http://192.168.1.194:9222 I get the list of sessions just fine and upon selecting one the dev console opens but it doesn't start the websocket connection to ws://192.168.1.194 so the screencast and remote debugging capabilities are not available.
Here's that failed example:
I've captured har files and uploaded them here if you want to take a look
Using the following steps I was able to debug remotely. However the screencast functionality did not work. Ultimately that's what I needed so this is only a 50% solution in my case.
So, as noted above in the comments, what's blocking remote debugging from working is that the chrome debugger links out to https://chrome-devtools-frontend.appspot.com/..... and passes a value of ws://192.168.1.194 for the websocket parameter. Any browser will inherently block this, based on it being mixed content - i.e: https + ws
What's needed here is to run the chrome dev tools frontend on a http server
and direct your chrome instance to that server instead of the appspot instance.
Solution Steps
1 Install depot_tools (pre-requisite for building)
https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up
2 Checkout the devtools-frontend repo
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#checking-out-source
3 Build chrome devtools frontend
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#build
4 Start the devtools-frontend http server
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#running-in-hosted-mode
5 Run 2 instances of chrome and use one to debug the other
5.1 Start first instance of chrome headless
...with remote debugging enabled. See the python way in the question above or do it from the command line with the same arguments
5.2 Start a second instance of chrome
...using a different user data dir --user-data-dir=<some-path>
5.3 Navigate to http://192.168.1.194:9222
Use whatever the IP address of the first chrome instance is and the port that you chose.
5.4 Create a link to the local dev server
The 2nd instance of chrome will now be showing you links to debug each of the open tabs of the 1st instance. However the links will still to go https://chrome-devtools-frontend.appspot.com/..... You'll need to copy n paste the link you want and replace the hostname with the hostname of the devtools frontend that you started in step 4
Walla!!
If you figure out how to get the screencast working please comment below! 🙏
N.B:
I also tried using the npm run server command in the devtools frontend but for some reason that server didn't work at all ¯\_(ツ)_/¯
I am getting Error in Communicating with Remote browser. It may have died when closing an existing browser created by protractor and switching to newly created window and then finding element by Link Text. Below is the code snippet. Kindly help in resolving the issue.
browser.driver.getAllWindowHandles().then(function(handles){
browser.driver.switchTo().window(handles[0]);
browser.driver.close();
browser.driver.switchTo().window(handles[1]);
});
element(by.linkText('connect')).isPresent(); // While Executing This code it throws the above error and Fails...
I'm working on a suite of Selenium WebDriver (not Selenium RC and not using Selenium-Server) tests that are being executed by a command-line call to MSTest. I've broken them into test classes for each browser we plan on testing (Chrome, Firefox and IE9, for now) and each test class has a startup method that logs in to the system under test and then executes the test(s) requested and a TearDown method that closes the browser using WebDriver.Quit().
On my development machine everything is hunky-dory, but on our build machine the class initialization/start-up method executes fine and logs into the site, but as soon as the first actual test starts the test runner closes with the error message:
OpenQA.Selenium.WebDriverException: Unexpected error. System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:59982
obviously the port changes depending on which browser's being tested; when I run the whole suite I get errors on different ports for the tests for IE, Firefox, and Chrome - two errors for each browser (as the suite currently has two tests for each browser)
Windows Firewall is off for the build machine, and checking netstat before running the tests shows that the port's not in use; if I debug the tests and stop after the startup code runs but before the test runs, of course the port is in use. 127.0.0.1 and localhost are the same as well.
I get the same error whether or not I call the test via the command line, run/debug it from within Visual Studio using the VS Test tools, or by executing my console app, which calls MSTest via Process.Start(). The exception is thrown on the first FindElement() call.
Where can I start looking to figure out why this is failing on the build machine and not on my dev box?
The issue here was that in trying to implement some more robust error handling during startup I place a call to the Teardown code in the finally block of a try/catch wrapped around the login code, so as soon as the test harness was done logging in I was closing and cleanin up the WebDriver instance, so when the test ran there wasn't a WebDriver there to communicate with.
I suspect when I as looking at the "same" code on my dev machine the libraries that were actually running didn't have that block in them.
When you run an application from Visual Studio it fires up a server listening on a certain port. In your case 59982.
You need to actually have your web application running on its own on the test environments before running your test against it.
On your dev machine your application is running on that port. I'm guessing on your remote machines that is not the case.