Protractor: Protractor tests fail on chrome v56 & v57 - chrome not reachable

[qualityshepherd]

I 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

[NickTomlin]

Hmm, these issues can be tough to debug; i've seen this happen intermittently on Debian boxes with versions of Chromedriver/Selenium and it's usually fixed by a patch in either of those projects.

There's often nothing that we can do in Protractor core but we can try to remove as many variables as possible. Do you have an example repository that I can use to try and repro on an ubuntu VM? I'm assuming this probably happens regardless of the code, but do you also experience it running the example repo?

Also, what is your exact chrome version?

[qualityshepherd]

Yeah, this one was a total pain to debug. This definitely seems like a chrome issue, but wanted to see if maybe this was known, or my brain is just being dumb. I sent it to chrome... so we'll see.

Solution for now is DO NOT UPGRADE CHROME PAST v55 UNDER ANY CIRCUMSTANCE :)

[qualityshepherd]

Also... in an unrelated issue... GO BUCKY!!!1!

[NickTomlin]

Sounds good i'll leave this open for a bit to collect any additional information; i'll plan on closing it in a week or so since the resolution needs to be external. Thanks for picking things up with chrome. Go bucky indeed :)

[qualityshepherd]

Sweet! (as in 16) Thanks, Nick.

[joshuacano]

I am also having the same problem on my mac.

[NickTomlin]

@joshuacano (and anyone else) can you post your full specs:

• Protractor Version
• Chrome version (Probably 57 😄 )
• Chromedriver version
• Selenium Standalone version
• Whether or not you can reproduce it with the example

I'm not able to reproduce on OSX

[m-ajitabh]

Update web driver for chrome v57

[dinvlad]

This occurs for me as well, whether I use Xvfb or the new --headless configuration, with
Protractor 5.1.0, Chrome 57.0.2987.110, ChromeDriver 2.28, Selenium 3.3.1.

So I cannot run Protractor at all on a CI server (CodeBuild on Ubuntu 14.04).

[qualityshepherd]

So I'm not crazy! Well... about this.

@dinvlad, I was able to run my CI by reverting to Chrome v55, which works with Protractor 5.x.

[NickTomlin]

Interesting, this could be a nix + chrome issue then

[dinvlad]

Actually, looks like Karma is not runnable on that system either. So most probably the nix (I think it's Amazon's own Docker image, to which unfortunately I have no access other than through CI). On Cloud9, which also runs 14.04, both frameworks run fine with the same settings (but only for Xvfb).

Without Xvfb, I was able to run Karma using the '--headless' option for Chrome as well on Cloud9. But Protractor refuses to eat it for some reason (it does run Chrome with that option, but still hangs). That could indicate Protractor's issue.

@qualityshepherd, could you try running Chrome with
--headless --disable-gpu --remote-debugging-port=9222, both in Karma and Protractor configs? Would be interesting to see if that fixes your setup in both cases or either one or not at all. https://github.com/angular/protractor/issues/4146#issuecomment-288870475

[joshuacano]

@NickTomlin Apologies for not responding earlier. I could not reproduce the problem via the standalone example you gave. I diagnosed the issue and it is related to running an old version of karma with the latest protractor. I had to upgrade karma to get this to work correctly.

[dinvlad]

So I've got a bit more consistency with this. Karma runs fine for 57 both on what I consider "local" system (Cloud9), even though it's headless, and "remote" (CI on AWS), but _only_ when I use --headless flag instead of Xvfb (which is nice by itself). Alternatively, Karma also runs fine _with_ Xvfb on the "local" system.

However, Protractor fails to run with this flag on either system. I use the same Chrome flags for both frameworks. At this point it appears that either Protractor or ChromeDriver are unable to communicate with Chrome given these flags. Protractor still does run with Xvfb on the "local" system though (a bit of good news).

[dinvlad]

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:

  capabilities: {
    browserName: 'chrome',
    chromeOptions: {
      args: [
        "--headless",
        "--disable-gpu"
      ],
    },
  },

@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.

[qualityshepherd]

Neat! I was not aware of the --headless option. I learned something today! TMYK. Thanks @dinvlad, I'll give it a go.

For others, here's the gist...

[qualityshepherd]

[rant]
Wasted another day on this today. There is a problem, on linux (ubuntu 16.04), and protractor 5.1.1, and chromedriver 2.28-2.29, and chrome 56+. It does not work and lucky for me, my automation requires it.

Have I mentioned that automation is silly and should be avoided?
[/rant]

[dinvlad]

What's failing?

[NickTomlin]

I'm going to go ahead and close this since it seems to be a chromedriver issue and there's nothing really actionable on the protractor side of things. Sounds like there are a few ongoing threads here that it might be useful to collect even if this issue closes.

It may be worth creating (and then answering) a StackOverflow question about this as "documentation" as well.

Thanks for doing digging and discovery here; y'all are awesome 😄

[qualityshepherd]

Yeah, there's some weird stuff going on in chromedriver currently. I can't quite nail down the exact issue. My rant above was a day where my ci build stopped working (likely Codeship change), which was a similar issue to this one. I got it fixed, then the next morning, my fix broke :) Fun times.

I was also seeing funky behavior using the later chromedriver version... which _seems_ to resolve only when backing up to v2.25 (with chrome v55). Which is what I'm running successfully now.

I think there's also an issue whereby Protractor will select the _older_ chromedriver installed (eg. if you had 2.27 & 2.29, i'll use 2.27). Assuming this is _not_ the expected behavior (@NickTomlin?), this is very likely causing some of the random issues people are reporting around the internets.

[dinvlad]

Probly an afterthought, but I also noticed that too many Github API attempts to download some Chromedriver files lead to throttling errors, and fail builds as a result because Protractor cannot download some jars. Not sure if this needs to be addressed on the Protractor or Chromedriver side (if at all; i.e. we cannot do anything about it unless there are other "mirrors" for those files).

[heathkit]

FYI guys, --headless is neat but it's extremely new. It's only in Chrome 59, which as of this date is still in beta. You might see chromedriver bugs specific to headless or specific to that version of chrome.

Issues like this are most likely not related to Protractor, but to the combination of Selenium Standalone server, chromedriver, and Chrome that you're using.

Except for cases where Protractor is accidentally using an outdated chromedriver or failing to download it, those are things we can fix. We've had some issues with people having a globally installed version of webdriver-manager that was different than their project, which can sometimes cause problems like that.

[qualityshepherd]

SOLVED:

I found some time to investigate this, and finally figured it out. Something in Chrome v56+ changed, so that if you're running it via Protractor (or anything), on a Linux server, as _root_, it will not start and fail your tests.

Yes, yes... don't run as root. Whatever. This really sucked because it worked up to v56, and I didn't see a notice of the change. It also took days to debug and refactor around.

So there you go... the solution is to _not_ run chrome as root. Create a new user to run your tests with. But add them to sudoers so you can start xvfb ;)

[qualityshepherd]

And yeah, @heathkit, I've had webdriver-manager sometimes use the older chromedriver, when multiple are installed. It got me to do a webdriver-manager clean more often.

All these great tools come with so many sharp edges :) Really glad there are great resources like github, and stackoverflow to help sort them out. Hope my answer above somes some folks some time, as so many answers have saved mine.

[dinvlad]

Hopefully, --headless will become stable enough so we don't have to run Xvfb in the first place. So far, I hadn't had any issues with it. Also, not sure why but it's actually already in 58 on the 'stable' branch. As judged by 'google-chrome-stable' package.

[qualityshepherd]

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

[rafaelcs]

@qualityshepherd Could you post examples here of your solution? This error is killing me when running tests on Codeship

so that if you're running it via Protractor (or anything), on a Linux server, as root, it will not start and fail your tests.

Yes, yes... don't run as root

Example?

[qualityshepherd]

Sure @rafaelcs, you just need to create a new user on your linux box, add them to sudo, and run your tests as that user. I have a script that builds my servers, so I added the following to automate the creation of a new user:

# add new user
adduser --disabled-password --gecos ""YOUR_USERNAME
# add user to sudoers
echo 'YOUR_USERNAME  ALL=(ALL:ALL) ALL' >> /etc/sudoers
# set password
sudo passwd YOUR_USERNAME

[kumarvarun1252]

@qualityshepherd I am seeing the same issue in the Jenkins job. Tests run fine locally on Mac, but not on Jenkins server which is on Linux. I don't have access to our Jenkins server :|

google-chrome 60.0 Protractor 5.1.2 Chrome Driver 2.28, 2.33 (Tried both) Selenium Standalone Server 3.6.0 OS Linux

[rafaelcs]

This error is no longer happening to me since when I changed my projects to circleCI and before starting the tests I install the latest version of chrome on the server (linux) via command line.

Example:

- curl -L -o google-chrome.deb https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
- sudo dpkg -i google-chrome.deb
- sudo sed -i 's|HERE/chrome\"|HERE/chrome\" --disable-setuid-sandbox|g' /opt/google/chrome/google-chrome
- rm google-chrome.deb

[dinvlad]

Also works for me with CircleCI, although I din't have to install the browser - just use circleci/node:7-browsers or a similar image, if possible.

[rohithegde]

Faced similar issue with a Docker image (https://hub.docker.com/r/webnicer/protractor-headless/). This thread helped me to realize the issue. Using an older image associated with Chrome 55 fixed the issue.

[stemkar123]

With latest version of Chrome, Protractor not working. I am just able to load the URL. Further commands like sendleys,getText etc are not working. No error shown in log.

Chrome version: 66
Protractor- 5.3.0
ChromeDriver- 2.38
selenium-server-standalone- 3.12.0

[m-ajitabh]

update webdriver manager also

Thanks
Ajitabh Ranjan
Mob: [phone]

On Tue, May 15, 2018 at 11:09 AM, stemkar123 [e-mail]
wrote:

With latest version of Chrome, Protractor not working. I am just able to
load the URL. Further commands like sendleys,getText etc are not working.
No error shown in log.

Chrome version: 66
Protractor- 5.3.0
ChromeDriver- 2.38
selenium-server-standalone- 3.12.0

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/angular/protractor/issues/4164#issuecomment-389048762,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOad57mC7_Ydp5j8nR36s-UzpQMDNYAgks5tymn5gaJpZM4MheuL
.

[stemkar123]

somehow I am able to send keys. But there is another issue I am facing i.e webelement is not getting clicked with click() function. I have to use "browser.executeScript("arguments[0].click();", )" statement to click & this is working fine.

Any idea why this is happening & how to resolve this