TestCafe fails with latest stable chrome version 122.0.6261.57

[codambro]

What is your Scenario?

Running testcafe with chrome:headless and the latest version of chrome installed

What is the Current behavior?

Error: Unable to open the "chrome:headless" browser due to the following error:

Error: No inspectable targets
    at defaultTarget (/home/circleci/project/node_modules/chrome-remote-interface/lib/chrome.js:48:23)
    at Chrome._fetchDebuggerURL (/home/circleci/project/node_modules/chrome-remote-interface/lib/chrome.js:194:28)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Chrome._start (/home/circleci/project/node_modules/chrome-remote-interface/lib/chrome.js:141:25)
    at BrowserConnection._runBrowser (/home/circleci/project/node_modules/testcafe/src/browser/connection/index.ts:290:32)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

What is the Expected behavior?

Tests run

What is the public URL of the test page? (attach your complete example)

any. google.com

What is your TestCafe test code?

fixture.page("https://www.google.com")

test("Test", async t => {
  await t.expect(true).ok();
});

Your complete configuration file

No response

Your complete test report

No response

Screenshots

No response

Steps to Reproduce

1.Run testcafe with latest chrome

TestCafe version

3.5.0

Node.js version

No response

Command-line arguments

api runner

Browser name(s) and version(s)

Chrome 122.0.6261.57

Platform(s) and version(s)

Ubuntu

Other

No response

[craiggunson]

Same here.
Google Chrome 122.0.6261.57 has been installed to /usr/bin/google-chrome-stable
ERROR Unable to open the "chrome:headless....

[Adam-Gillespie345]

Experiencing the same problem

[Eng-raghad]

We're getting the same issue started yesterday with TestCafe 3.1.0 & it affects all the remote runs on Circle. I hope this can get significant attention to get us unblocked.

[josephfrazier]

I'm experiencing the same issue on TestCafe 2.6.2, using Chrome and ChromeDriver 122.0.6261.57:

ERROR Unable to open the "chrome:headless" browser due to the following error:

Error: No inspectable targets
    at defaultTarget (/home/app/node_modules/chrome-remote-interface/lib/chrome.js:48:23)
    at Chrome._fetchDebuggerURL (/home/app/node_modules/chrome-remote-interface/lib/chrome.js:194:28)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Chrome._start (/home/app/node_modules/chrome-remote-interface/lib/chrome.js:141:25)

Type "testcafe -h" for help.

[Jgrabenbauer]

Getting the same issue here, it happened around 5:00pm EST.

[JPrymek-Change]

Also ran into this issue with TestCafe 3.5.0 when using the latest Chrome 122.0.6261.57 on a CircleCi Ubuntu container.
Pinning our Chrome version to 121.0.6167.184 worked as a short-term fix.

[PavelMor25]

Currently, we can't reproduce the issue (chrome 122.0.6261.57 / node 18 - 20 / ubuntu 22.04 - 20.04 / testcafe 2.6.2 - 3.1.0 - 3.5.0).

As soon as we are able to reproduce it, we will address it immediately.

Also, Chrome has released a new version 122.0.6261.69. Does the issue occur with it?

[AlexGrisin]

This is reproducible for me when running TestCafe tests inside the docker container with node:18.17-bullseye while running just fine on Mac. Both have current latest stable Chrome installed.

TestCafe v3.5.0

[belug23]

We're having the issue with a freshly pull version of the test-café docker on version 3.5.0 which uses chromium 122.0.6261.57-r0

I've been able to return our tests to the normal by forcing the version to chromium 121.0.6167.184-r0 from alpine v3.19 community by inheriting from the original docker and adding these lines:

FROM testcafe/testcafe:3.5.0 as testcafe-chromium-fix

USER root
RUN apk --no-cache $ALPINE_REPOS --repository http://dl-cdn.alpinelinux.org/alpine/v3.19/community/ upgrade && \
 apk --no-cache $ALPINE_REPOS --repository http://dl-cdn.alpinelinux.org/alpine/v3.19/community/ add 'chromium=121.0.6167.184-r0'
USER user

and then using testcafe-chromium-fix:latest in my docker command.

[JPrymek-Change]

I'm still seeing the issue with Chrome 122.0.6261.69
Also - we're installing TestCafe on one of CircleCi's Docker runners, which uses cimg/node:18.9.1-browsers image. We're not building the custom docker image ourselves.

[PavelMor25]

Guys, please share a working example where we can reproduce the issue. As soon as we have it, we will thoroughly investigate the issue. Specify all the details that you find important to reproduce the problematic behavior (all the environment details, NodeJS version, OS version, etc.).

[dcsaszar]

.circleci/config.yml

version: 2.1
orbs:
  browser-tools: circleci/browser-tools@1.4.8
  node: circleci/node@5.2.0
jobs:
  testcafe-chrome:
    docker:
      - image: cimg/node:lts-browsers
    resource_class: small
    steps:
      - browser-tools/install-chrome
      - checkout
      - run: npm i testcafe
      - run: npx -- testcafe chrome:headless test.js
workflows:
  run-tests:
    jobs:
      - testcafe-chrome

test.js

fixture`Test`.page`https://example.org`;
test("test", async (t) => {
  await t;
});

Logs

Env

Build-agent version 1.0.224070-c3d6799a (2024-02-22T14:18:38+0000).
System information:
 Server Version: 24.0.9
 Storage Driver: overlay2
  Backing Filesystem: xfs
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Kernel Version: 5.15.0-1053-aws
 Operating System: Ubuntu 20.04.6 LTS
 OSType: linux
 Architecture: x86_64

Starting container cimg/node:lts-browsers
cimg/node:lts-browsers:
  using image cimg/node@sha256:1abceae9c9423f54a372eb28a75694ecd0f436ea8eae703e8fb25f66827b23a1
  pull stats: Image was already available so the image was not pulled
  time to create container: 68ms
Warning: No authentication provided, using CircleCI credentials for pulls from Docker Hub.
  image is cached as cimg/node:lts-browsers, but refreshing...
lts-browsers: Pulling from cimg/node
Digest: sha256:1abceae9c9423f54a372eb28a75694ecd0f436ea8eae703e8fb25f66827b23a1
Status: Image is up to date for cimg/node:lts-browsers
Time to upload agent and config: 227.361325ms
Time to start containers: 236.573336ms

Chrome install

Unpacking libu2f-udev (1.1.10-3build2) ...
Selecting previously unselected package libvulkan1:amd64.
Preparing to unpack .../2-libvulkan1_1.3.204.1-2_amd64.deb ...
Unpacking libvulkan1:amd64 (1.3.204.1-2) ...
Selecting previously unselected package google-chrome-stable.
Preparing to unpack .../3-google-chrome-stable_122.0.6261.69-1_amd64.deb ...
Unpacking google-chrome-stable (122.0.6261.69-1) ...
Selecting previously unselected package mesa-vulkan-drivers:amd64.
Preparing to unpack .../4-mesa-vulkan-drivers_23.2.1-1ubuntu3.1~22.04.2_amd64.deb ...
Unpacking mesa-vulkan-drivers:amd64 (23.2.1-1ubuntu3.1~22.04.2) ...
Selecting previously unselected package systemd-hwe-hwdb.
Preparing to unpack .../5-systemd-hwe-hwdb_249.11.5_all.deb ...
Unpacking systemd-hwe-hwdb (249.11.5) ...
Setting up systemd (249.11-0ubuntu3.12) ...
/usr/lib/tmpfiles.d/static-nodes-permissions.conf:17: Failed to resolve group 'kvm'.
/usr/lib/tmpfiles.d/static-nodes-permissions.conf:18: Failed to resolve group 'kvm'.
/usr/lib/tmpfiles.d/static-nodes-permissions.conf:19: Failed to resolve group 'kvm'.
Setting up udev (249.11-0ubuntu3.12) ...
A chroot environment has been detected, udev not started.
Setting up libvulkan1:amd64 (1.3.204.1-2) ...
Setting up systemd-hwe-hwdb (249.11.5) ...
Setting up mesa-vulkan-drivers:amd64 (23.2.1-1ubuntu3.1~22.04.2) ...
Setting up systemd-sysv (249.11-0ubuntu3.12) ...
Setting up libu2f-udev (1.1.10-3build2) ...
Setting up libpam-systemd:amd64 (249.11-0ubuntu3.12) ...
Setting up google-chrome-stable (122.0.6261.69-1) ...
update-alternatives: using /usr/bin/google-chrome-stable to provide /usr/bin/x-www-browser (x-www-browser) in auto mode
update-alternatives: using /usr/bin/google-chrome-stable to provide /usr/bin/gnome-www-browser (gnome-www-browser) in auto mode
update-alternatives: using /usr/bin/google-chrome-stable to provide /usr/bin/google-chrome (google-chrome) in auto mode
Processing triggers for dbus (1.12.20-2ubuntu4.1) ...
Processing triggers for libc-bin (2.35-0ubuntu3.5) ...
Google Chrome 122.0.6261.69  has been installed to /usr/bin/google-chrome-stable

Test run

ERROR Unable to open the "chrome:headless" browser due to the following error:

Error: No inspectable targets
    at defaultTarget (/home/circleci/project/node_modules/chrome-remote-interface/lib/chrome.js:48:23)
    at Chrome._fetchDebuggerURL (/home/circleci/project/node_modules/chrome-remote-interface/lib/chrome.js:194:28)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Chrome._start (/home/circleci/project/node_modules/chrome-remote-interface/lib/chrome.js:141:25)

Type "testcafe -h" for help.

Exited with code exit status 1

[codambro]

I am not seeing it on my local machine, but am seeing it in CircleCI.
I created this bare-bones repo with a CircleCI config to reproduce the issue:
https://github.com/codambro/testcafe-issue-8145

[belug23]

I've made a repository with a custom Dockerfile and the instruction on how to build/run it to reproduce the issue.

https://github.com/belug23/testcafe-issue-8145

At the moment of building it, the docker used:

• nodejs 20.11.1-r0
• 122.0.6261.57-r0

I've also tested it with nodejs 20.10.0-r1 same issue.

[github-actions]

We appreciate you taking the time to share information about this issue. We reproduced the bug and added this ticket to our internal task queue. We'll update this thread once we have news.

[Bayheck]

We found that the issue relates to the chrome --headless flag used in TestCafe chromium:headless.

As a workaround, please try running your tests with chromium --headless=new.

For example: chromium:headless becomes chromium --headless=new.

Please let us know if you encounter any issues.

[rowlo]

When I tried the workaround it did not work for me:

> E2E_RUN=true testcafe chromium --headless=new tests/e2e/ --hostname 127.0.0.1 --app 'pnpm dev'
ERROR Your Linux version does not have a graphic subsystem to run chromium with a GUI. You can launch the browser in headless mode. If you use a portable browser executable, specify the browser alias before the path instead of the 'path' prefix. For more information, see https://testcafe.io/documentation/402828/guides/concepts/browsers#test-in-headless-mode
Type "testcafe -h" for help.

Then I tried @omerhakanbilici variant. That one worked for me as well.

[alexandruSuciuRinf]

Any news on this issue? I tried the above solution and it's not working.

[Bayheck]

Hello, @alexandruSuciuRinf

Please create a ticket using this template and also share a Minimal Working Example in that ticket so that the TestCafe team can research the issue and help you.

[Bayheck]

We found that the issue is related to old headless not providing the target list.

Here is the issue on Chromium: https://issues.chromium.org/issues/40256248.

Old headless is going to be discontinued.

However, the new headless is not yet stable enough at this moment for TestCafe to use it as default. The solution for now is to use the workaround above.

[jsedanoj]

Pity.

The solution for now is to use the workaround above.

Unfortunately, the workaround does not work for everybody. At least it does not work for me.

At least, you have diagnose now.

[Bayheck]

Hello @jsedanoj,

Please create a ticket - use this template - and share a Minimal Working Example in that ticket so that the TestCafe team can research the issue and help you.

[pbilstein]

We found that the issue relates to the chrome --headless flag used in TestCafe chromium:headless.

As a workaround, please try running your tests with chromium --headless=new.

For example: chromium:headless becomes chromium --headless=new.

Please let us know if you encounter any issues.

Same problem with new chrome here. The workaround functions in general, but it seems that t.pressKey(), for example t.pressKey("backspace") does not have any effect then, and we are using it in our tests alot. Works normal without the workaround and non-headless.

[Bayheck]

Hello @pbilstein,
Please create a ticket - use this template - and share a Minimal Working Example in that ticket so that the TestCafe team can research the issue and help you.

[Aleksey28]

fix #8151

[Parvathy-Krishnan]

Hi @Aleksey28 @Bayheck
May I know what is the fix given?
Should we continue to use the workaround or should we revert it to the original state?
Workaround: chromium --headless=new
Orignal state: chrome:headless

[Bayheck]

Hello,

The only current solution is to use the workaround.

In the next TestCafe version, headless new will be the default and you will be able to use chrome:headless again.

[danielhammerl]

For me this workaround unfortunately doesnt work.

With this line: 'testcafe "chromium --headless=new" tests/ui/index.ts'
I always receive following error:

Error: connect ECONNREFUSED 127.0.0.1:41601
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1605:16)
at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17)

Trying with latest testcafe version within latest testcafe docker container. Port number in error message seems random and is always different

[Bayheck]

Hello,

Try these lines:

testcafe chromium --headless=new

or

testcafe 'chrome --headless=new'

Please be aware of the quotes.

In TestCafe v3.6 and later, headless=new is default, and you can use chrome:headless again.