Protractor tests fail on chrome v56 & v57 - chrome not reachable
See original GitHub issueI run Protractor tests on an Ubuntu 16 server via xvfb. This was working fine with 4.0.14 and google-chrome-stable v54. When I updated to Protractor 5.1.1 (which requires Chrome v55+), and chrome 57 (latest), my tests stopped working, and would timeout with:
[chrome #01-1] WebDriverError: chrome not reachable
[chrome #01-1] (Driver info: chromedriver=2.28.455506 (18f6627e265f442aeec9b6661a49fe819aeeea1f),platform=Linux 4.4.0-67-generic x86_64)
[chrome #01-1] at WebDriverError (./node_modules/selenium-webdriver/lib/error.js:27:5)
[chrome #01-1] at Object.checkLegacyResponse (./node_modules/selenium-webdriver/lib/error.js:505:15)
[chrome #01-1] at parseHttpResponse (./node_modules/selenium-webdriver/lib/http.js:509:13)
[chrome #01-1] at doSend.then.response (./node_modules/selenium-webdriver/lib/http.js:440:13)
[chrome #01-1] at process._tickCallback (internal/process/next_tick.js:103:7)
[chrome #01-1] From: Task: WebDriver.createSession()
[chrome #01-1] at Function.createSession (./node_modules/selenium-webdriver/lib/webdriver.js:777:24)
[chrome #01-1] at Function.createSession (./node_modules/selenium-webdriver/chrome.js:709:29)
[chrome #01-1] at Direct.getNewDriver (./node_modules/protractor/lib/driverProviders/direct.ts:90:25)
[chrome #01-1] at Runner.createBrowser (./node_modules/protractor/lib/runner.ts:225:39)
[chrome #01-1] at q.then.then (./node_modules/protractor/lib/runner.ts:391:27)
[chrome #01-1] at _fulfilled (./node_modules/q/q.js:834:54)
[chrome #01-1] at self.promiseDispatch.done (./node_modules/q/q.js:863:30)
[chrome #01-1] at Promise.promise.promiseDispatch (./node_modules/q/q.js:796:13)
[chrome #01-1] at ./node_modules/q/q.js:556:49
[chrome #01-1] at runSingle (./node_modules/q/q.js:137:13)
Impact:
Does not occur with chrome v54 or v55
Occurs with both directConnect
and when specifying the correct seleniumServerJar
in config
Occurs with latest Protractor v4x and v5x
Node v6.10.0
Issue Analytics
- State:
- Created 7 years ago
- Reactions:2
- Comments:35 (6 by maintainers)
Top Results From Across the Web
webdriver - Protractor tests failing randomly - screenshot error ...
2) Add the path to the Chrome browser binary (the actual browser, not driver) file in ChromeOptions. This is needed when running headless....
Read more >Failed to take screenshot and some strange extension output
I am on mac. I am using real chrome browser and not headless. This happened twice and both the times since it was...
Read more >Protractor test with headless Chrome , it failed to start: crashed
Am trying to run integration tests inside docker container using Headless chrome browser. and getting this error. [10:05:40] E/runner - Unable to start...
Read more >Change Log - XQual
Ability to create and links failed tests to integrated bug and/or bugs coming from different third-party systems. * Results tampering (updating results and ......
Read more >the 2 of 3 and 4 0 5 to 6 a 7 in 8 1 9 for 10 image 11 2 12 is 13
... 238 error 239 help 240 what 241 work 242 f 243 07 244 glossary 245 test 246 ... 18958 steller 18959 144k...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
UPDATE: Got it to work!
According to https://bugs.chromium.org/p/chromedriver/issues/detail?id=878, it’s ChromeDriver that doesn’t like mixing Chrome’s
--remote-debugging-port
option, because it’s connecting over that same port if I understand that correctly. So I’ve just removed that option from Protractor config, and voila:@qualityshepherd, you might be interested in using this option instead of Xvfb - see if that solves your issues as well. Granted that doesn’t address the problem with Xvfb itself, but if we can avoid another tool that’s even better, IMO.
Agreed… I’d love to see all the browsers allow headless runs. I’d love to run Safari at all 🚎
Oh Safari… the new IE6