TestCafe fails with latest stable chrome version 122.0.6261.57

codambro commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

Experiencing the same problem

Eng-raghad commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

JPrymek-Change commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

.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 commented 9 months ago

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 commented 9 months ago

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[bot] commented 9 months ago

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 commented 9 months ago

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.

danielvoxy commented 9 months ago

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.

This workaround worked for us! Thanks, @Bayheck

In our case, we replaced chrome:headless with chromium --headless=new.

belug23 commented 9 months ago

I can confirm that using --headless=new with the docker example that I've created for the issue.

I've updated the chromium version of my docker to 122.0.6261.94-r0
It's tested with docker run --rm testcafe:issue-8145 chromium --headless=new test.js and it ran well.
I've tested with docker run --rm testcafe:issue-8145 chromium:headless test.js and it failed to confirm that it wasn't fixed via a Chromium update in between.

omerhakanbilici commented 9 months ago

thank you for the workaround, for me, there was another trick to be able to run with the new headless mode: testcafe 'chrome --headless=new' be aware of the quotes

rowlo commented 8 months ago

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 commented 8 months ago

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

Bayheck commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 7 months ago

fix https://github.com/DevExpress/testcafe/pull/8151

Parvathy-Krishnan commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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.

DevExpress / testcafe