-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Headless Chrome times out without executing any tests #154
Comments
Can someone address this please. I've tried so many karma configurations, using different package versions etc to make it work, but still no luck. |
The way that you define CHROME_BIN has been updated in recent version (see the readme for more details). It is now:
|
@saimaheshgaya this basically reaches the same result |
try Also adding |
@saimaheshgaya That is not going to resolve the issue. If you increase the timeout to x, it times out after those x ms. |
appears to have worked for us. |
|
Still no luck here. |
Same here! Hey @vargarobert I have posted the issue on the puppeteer's repo and they closed mine asking me to remove karma and try it out. I have to do that. Link here. Maybe try that out. |
@applecool Pupetteer works as expected, just tried it out. It must be something related to karma-chrome-launcher not launching the headless browser. |
@vargarobert That's cool. So, its clearly a problem with the |
@applecool The launcher is starting incorrect browser "Starting browser Chrome". it should launch "ChromeHeadless" Check my log below (mine is OSX as well, not Linux). When logs start flushing from HeadlessChrome 0.0.0 Google chromeheadless stated its execution, means Karma-chrome-launcher is fine. Did you report this to google chrome headless? @applecool @vargarobert package.json my karma.conf.js starts with My browser in karma.conf.js Im not using any custom launcher configurations. All options you have given are handled by karma-chrome-launcher line 168 in "node_modules/karma-chrome-launcher/index.js" This is my log. |
Thanks a lot @kumvem for the information. Yes, I did report it on the puppeteer. I didn't had any problems on OSX either. And the log which I shared is from the linux execution not OSX.
I am completely confused with that log. Nevertheless, all the tests execute successfully. You have mentioned that you aren't using puppeteer and still be able to execute the tests with the chrome headless. So, I am assuming you installed Chrome GUI on your machine which is being launched by the I will try to run the tests with ChromeHeadless without the puppeteer and see what's going on. Thank you again. |
@kumvem I removed puppeteer, and also the customLaunchers property in the config. As the base property in the customLaunchers was assigned to
Log on OSX:
Successfully runs on OSX and executes the tests without Puppeteer. No, flags, nothing. Works out of the box with just the browser set to Same config, Log when running on Linux Server:
😞 |
@vargarobert any luck? |
I've tried numerous combinations on different platforms. I would like to be able to run it independently of the Chrome GUI installed (just like phantomJS, slient). You download a binary for your platform and run heedlessly. Simple - to work in any environment. Here is where the problems start to appear. You set CHROME_BIN or CHROMIUM_BIN to your local chromium binary or puppeteer chromium binary and it doesn't lunch (not even when you use ChromiumHeadless, regardless of the platform and browser configuration - I've tried all of them). We should try to get an actual chrome binary from somewhere and try it out. Like I said so far I've used puppeteer and local binary (downloaded from https://www.chromium.org/getting-involved/download-chromium) |
Thanks for sharing the info @vargarobert I wish it was as simple as Phantom JS though. |
@applecool |
@kumvem I didn't get the timeout issue on Mac at all. seems like you misunderstood. I am getting timeout problem when executing on linux box. |
@applecool |
@michaelkrone I already have 120000ms. I re-tried it with much higher value of 3 and 5 minutes too. It's still the same. It just times out. And I have also tried on the Linux GUI (Ubuntu Desktop 16.0.4 LTS). Still the same. Doesn't work with ChromeHeadless. It's so annoying 😞 |
The workaround posted by @andrewl-telnyx appears to be working for me. I'm not using puppeteer. All I had to do was add this to my config: browsers: ['HeadlessChrome'],
customLaunchers:{
HeadlessChrome:{
base: 'ChromeHeadless',
flags: ['--no-sandbox']
}
} It always timed out when using Edit: I may have spoken too soon. It's also timing out, but does occasionally succeed. 😢 |
@reduckted Which OS are you on? Linux or OSX? |
Sorry, should have mentioned that. I'm actually on Windows 10. |
@applecool FWIW we have a working Linux Mint (Ubuntu) and Alpine config using puppeteer, which I'll post here if it might help at all. This assumes that you have CHROME_BIN set with puppeteer:
... And then as to the actual Karma config:
This is done using:
... Our problem is the reverse. We can't get UPDATE: We also got it working on mac by switching the base to |
Having the same issue on Windows 7 I've tried all of the flags listed in this issue, but non help it connect. Task manager shows that Chromium is running, but for some reason it is not connecting to karma. Non headless chrome works fine. |
UPDATE: My issue was solved using the answer mentioned here karma-runner/karma#2652 (comment) I have the same issue on Windows 7. Tried with all flags and also with the custom launcher. No luck.
|
Posting for posterity. I had this same issue with a project dependent on Karma 1.7.0, so I switched from tl;dr: make sure you kill any servers running locally on your karma server's port (usually 8080) |
@NealAJohnson do you know how to make it to be waiting? |
No clue, I don't even know if that's configurable. |
An error [from 2017](karma-runner/karma-chrome-launcher#154) showed up, causing [this problem](https://github.com/polypoly-eu/polyPod/runs/3993971665?check_suite_focus=true) Maybe outside the scope of this PR, but this is the only place (maybe another, I'll have to check) where karma is used and I think it can be done in the same way by cypress, which is what we've settled for now.
* Updating a few services However, electron can't really be eliminated until #361 clears. * Fixes rdf-spec build error Thanks to this: Azure/azure-cosmos-js#395 Not entirely clear why this problem arose when we upgraded dependencies * 🐛 quashed here also (apparently) * ⬆️ fast_check to avoid error * Fixed here by ⬆️ * Fixed here by ⬆️ * Eliminates karma An error [from 2017](karma-runner/karma-chrome-launcher#154) showed up, causing [this problem](https://github.com/polypoly-eu/polyPod/runs/3993971665?check_suite_focus=true) Maybe outside the scope of this PR, but this is the only place (maybe another, I'll have to check) where karma is used and I think it can be done in the same way by cypress, which is what we've settled for now. * Remove karma from downstream deps ⚰️
For the ones that experience this issue with Angular. The problem is that the Angular build (webpack) is running in parallel with launching the Chrome browser. In a simple Angular project that is no big deal as the build is fast, but in a big Angular project the build chokes the system and launching the browser takes longer than Karma's The workaround using A better solution is to run webpack and launching the browser serially. I created a Karma framework type plugin that does just that. It makes sure Karma waits for the webpack build to complete before launching browsers.
plugins: [
require('./karma.waitwebpack'),
require('@angular-devkit/build-angular/plugins/karma'),
],
frameworks: ['waitwebpack', 'jasmine', '@angular-devkit/build-angular'], // waitwebpack must be before build-angular
function WebpackCompilerEventsPlugin(options) {
this.options = options;
}
WebpackCompilerEventsPlugin.prototype.apply = function(compiler) {
compiler.hooks.afterDone.tap('webpack-compiler-events-plugin', this.options.afterDone)
};
function waitWebpackFactory(config) {
return new Promise(resolve => {
let isFirstBuild = true;
config.buildWebpack.webpackConfig.plugins.push(new WebpackCompilerEventsPlugin({
afterDone: () => {
if (isFirstBuild) {
console.log('First webpack build done');
isFirstBuild = false;
resolve();
}
}
}));
});
}
waitWebpackFactory.$inject = ['config'];
module.exports = {
'framework:waitwebpack': ['factory', waitWebpackFactory]
}; With this plugin the output is always like:
|
I ran into this with my Angular project after upgrading to Angular 12, and no combination of the karma config recommended here was resolving it. I tried different browsers, both headless and non-headless, with no luck. Turns out, I had a compilation error in the This error was only getting logged with I ran the Karma tests using Chrome then opened up the Console in the browser opened by Karma. |
For us, we were getting the following:
I opened Chrome manually and checked to see if an update was pending. There was an update pending, we let it complete and the problem seems to have gone away. |
It started failing again, we increased |
@jr01 Your solution works perfectly for our large Angular monorepo. Thanks! |
…uild is complete This change is inspired by karma-runner/karma-chrome-launcher#154 (comment) which blocks Karma from launching the browsers until the compilation is complete. This is needed especially for large applications when using code-coverage where otherwise the users would have to fine-tune several Karma timeouts such as `captureTimeout` for various environments. Closes #22495 (cherry picked from commit 7ce5000)
…uild is complete This change is inspired by karma-runner/karma-chrome-launcher#154 (comment) which blocks Karma from launching the browsers until the compilation is complete. This is needed especially for large applications when using code-coverage where otherwise the users would have to fine-tune several Karma timeouts such as `captureTimeout` for various environments. Closes #22495
@jr01 Hello, By any chance, would you have an idea of why I would be receiving this error when utilizing your plugin? Thanks for your help!
|
@aruballo - Perhaps a different webpack version. I was using Angular 13.0 at the time. If you upgrade to https://github.com/angular/angular-cli/releases/tag/13.2.3 you don't need the workaround. |
Just replace |
The most helpful suggestion is here .
karma: 4.4.1
I struggle for few days with this issue, hope it helps someone. |
Hello guys I tried everything but not a single thing worked for me. You can try by commenting window.location.href. it will work. |
Ran into this same problem and commenting out |
I add |
I had a very similar issue. I didn't think twice and made strict dependencies in package.json for everything related to tests and it worked
|
I recently had this problem and what helped me was starting the browser without headless mode to see the real problem. The fix in my case was changing the listen address and hostname in the karma.conf:
|
Faced the same issue with connections and fixed by downgrading karma package from And adding
and |
This PR intends to fix the macOS CI timeout issue as an urgent fix. It includes a few changes: 1. upgrade karma version to 6.4.3 2. enlarge the timeouts 3. adding waitwebpack wrapper according to karma-runner/karma-chrome-launcher#154 (comment).
I have configured the headless chrome in my project getting rid of Phantom. When I run the tests on my OSX machine, all the tests get executed with the test runner on the headless chrome. But the same doesn't happen on my linux server. It connects to the socket and then after some time, it disconnects and shows the error message saying "Karma tests failed".
Error:
Here is my configuration:
Using
karma-chrome-launcher: "2.1.1"
. Tried with the latest2.2.0
version too. Tried withkarma: "1.5.0"
,"1.6.0"
, and the latest"1.7.1"
.I tried other flags like "
--no-sandbox
", "--disable-web-security
" as suggested on a bunch of issues on karma repo. But still no luck. Is there a fix or workaround for this issue? Is there a reason why it's not working on the Linux server [Ubuntu Server 14.04.5 LTS].The text was updated successfully, but these errors were encountered: