Skip to content
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

"Delaying execution, these browsers are not ready" Error #411

Closed
mpaulucci opened this issue Mar 19, 2013 · 43 comments
Closed

"Delaying execution, these browsers are not ready" Error #411

mpaulucci opened this issue Mar 19, 2013 · 43 comments
Labels

Comments

@mpaulucci
Copy link

Hi, I've been having this issue for a couple of weeks now, and its driving me nuts.

I have my setup configured to retest on every save, but now after a couple of changes in the code and saving, after 3 or 4 saves the tests don't run anymore and I get this message:

INFO [testacular]: Delaying execution, these browsers are not ready: PhantomJS 1.8 (Linux)

changing browser

INFO [testacular]: Delaying execution, these browsers are not ready: Chrome 25.0 (Linux)

As you can see, it happens when using Chrome as well as PhantomJS

Restarting Karma fixes the problem, but after a couple of saves I'm in the same situation.

Additional info: I'm on linux and using coffeescript.

@dignifiedquire
Copy link
Member

What version of Karma and Node are you using?

@mpaulucci
Copy link
Author

Node 0.8.20
Karma 0.8.0

This bug probably is related to something being wrong in my tests, because now I'm running one test individually and it works ok. Any ideas of a pattern I should look for?

@dignifiedquire
Copy link
Member

My best guess would be that there is something in your tests that doesn't terminate correctly and then the browser is not ready when the second test runs. Try running both with --log-level debug and post your output plus your config file.

@mpaulucci
Copy link
Author

Now it started to happen with a single test

INFO [watcher]: Changed file "foo.coffee". DEBUG [preprocess.coffee]: Processing "foo.coffee". DEBUG [karma]: Execution (fired by autoWatch) INFO [karma]: Delaying execution, these browsers are not ready: Chrome 25.0 (Linux) INFO [watcher]: Changed file "foo.coffee". DEBUG [preprocess.coffee]: Processing "foo.coffee". DEBUG [karma]: Execution (fired by autoWatch) INFO [karma]: Delaying execution, these browsers are not ready: Chrome 25.0 (Linux)

and when the error comes, the browser is always

Chrome 25.0 (Linux) is executing

and never returns to "Idle" state. When I refresh Chrome it works:

DEBUG [web server]: serving: /usr/lib/node_modules/karma/static/client.html
Chrome 25.0 (Linux): Executed 3 of 39 (skipped 8) DISCONNECTED (47.387 secs / 0.186 secs)
WARN [Chrome 25.0 (Linux)]: Disconnected
DEBUG [karma]: New browser has connected on socket SJpZJCivii7EYMXkwbGx
INFO [Chrome 25.0 (Linux)]: Connected on socket id SJpZJCivii7EYMXkwbGx
DEBUG [karma]: All browsers are ready, executing

It seems that the tests are not finishing, and the browser remains executing and never ends. I don't know why this behavior is not deterministic, though.

Config file:
https://gist.github.com/sammla/5198573

@vojtajina
Copy link
Contributor

Can you binary search for the test that is causing it and share the test ? Maybe we can prevent it from happening or at least show some error...

@mbielski
Copy link

I have been having this same problem, but I just found that it was running into confirm dialogs and location.href assignments and having problems with those. Once I get those cleared up I'll try again and see if I am still getting the same thing.

@vojtajina
Copy link
Contributor

Well, waiting for any dialog means the test did not finish and therefore
Karma was waiting for the previous execution to finish, which is correct
behavior.

We might intercept things like alerts() and stuff and at least show a
warning in CLI.

On Thu, Mar 21, 2013 at 3:17 PM, Michael Bielski
notifications@gh.neting.ccwrote:

I have been having this same problem, but I just found that it was running
into confirm dialogs and location.href assignments and having problems with
those. Once I get those cleared up I'll try again and see if I am still
getting the same thing.


Reply to this email directly or view it on GitHubhttps://github.com//issues/411#issuecomment-15269620
.

@mbielski
Copy link

Thank you Vojta, that would be helpful to see. I think we're looking into a different style of confirm dialog, one that would solve that problem. The redirects are still an issue though. I'm wondering if there is a way to mock the location object and add a preventDefault to the href assignment? Have to do some digging and see.

@vojtajina
Copy link
Contributor

You can do that inside your test code - if you really wanna call stuff like window.alert, just mock it out - monkey patch it. Eg. with jasmine spy:

spyOn(window, 'alert');

We should definitely prevent page reload, there's already an issue for it #27. I'm adding a note to myself to consider patching window.alert.

@vojtajina
Copy link
Contributor

@sammla Did you figure out which test is causing it ?

@mpaulucci
Copy link
Author

I am not really sure it is one test, most probably there are a couple of tests that fire up this problem. It is not that easy to isolate them because of the non deterministic behavior, for example:

I start Karma (with Chrome):
Executing 36 of 40 tests. (Chrome never returns back from "executing" state).
I refresh Chrome:
Executing 8 of 40 tests. (Chrome never returns back from "executing" state).
I refresh Chrome:
Executed 40 of 40 tests SUCCESS. (Chrome is on "idle" state).

If my problem was related to alerts or similar, wouldn't I get this issue on every run?

I will try to look further to see if there is a pattern, or to make a smallest test possible that behaves this way, but there is the possibility that every single test works ok when runned alone...

@vojtajina
Copy link
Contributor

@ sammla If you can't figure it out. Could you show me your project ? Maybe
through a hangout/skypescreen sharing or send me the files, I wouldn't
share it, I'm just curious what the issue is....

On Fri, Mar 29, 2013 at 7:27 AM, Martin Paulucci
notifications@gh.neting.ccwrote:

I am not really sure it is one test, most probably there are a couple of
tests that fire up this problem. It is not that easy to isolate them
because of the non deterministic behavior, for example:

I start Karma (with Chrome):
Executing 36 of 40 tests. (Chrome never returns back from "executing"
state).
I refresh Chrome:
Executing 8 of 40 tests. (Chrome never returns back from "executing"
state).
I refresh Chrome:
Executed 40 of 40 tests SUCCESS. (Chrome is on "idle" state).

If my problem was related to alerts or similar, wouldn't I get this issue
on every run?

I will try to look further to see if there is a pattern, or to make a
smallest test possible that behaves this way, but there is the possibility
that every single test works ok when runned alone...


Reply to this email directly or view it on GitHubhttps://github.com//issues/411#issuecomment-15642939
.

@nickdestefano
Copy link

+1. I am also having this issue.

@mxc
Copy link

mxc commented Mar 30, 2013

Also having this issue. Tried Firefox and chrome.

@mxc
Copy link

mxc commented Mar 30, 2013

if i remove the REQUIRE and REQUIRE_ADAPTER lines from the files property in the config file everything seems to work again.

@hjunaid
Copy link

hjunaid commented Mar 31, 2013

same problem with my test..

----------------e2e config --------
basePath = '../';

files = [
    ANGULAR_SCENARIO,
    ANGULAR_SCENARIO_ADAPTER,
    'e2e/*.js'
];

autoWatch = false;

browsers = ['Chrome'];

singleRun = false;

proxies = {
    '/' : 'http://localhost:8080/'
};

junitReporter = {
    outputFile : 'test_out/e2e.xml',
    suite : 'e2e'
};
-----Test Scenario---
'use strict';
describe("My Application", function () {
    describe("Search View", function () {

        beforeEach(function () {
            browser().navigateTo("/index.html");
//             console.log(browser().location().url())
//            expect(browser().location().url()).toBe('/');
        });

        it('should have be true', function() {
            input('field.serverName').enter('abc');
            element('#onSearchButton','test').click();
            expect(input('fields.serverName')).toBe('abc');
        });
  });
});
----Output-----
Chrome 26.0 (Windows): Executed 0 of 1 DISCONNECTED (50.206 secs / 0 secs)

@agsha
Copy link

agsha commented Apr 3, 2013

same problem with me too. Worked for me too when I removed REQUIRE and REQUIRE_ADAPTER. any resolution on this?

@adrian-chang
Copy link

+1 For Require and Require_Adapter causing karma to fail, it's also specifically related to require_adapter, I can write a basic jasmine test, without using define etc. anything related to requirejs, and it still hangs as long as I use the require_adapter.

-- update --

Actually I might of resolved my own issue, it might be due to the fact I had forgotten to always specifically load my main.js file, just a very strange reporting error.

@vojtajina
Copy link
Contributor

In general, when you get "delaying execution, waiting for...." that means the browser did not finish previous tests execution.

@amchang that sounds like you never called __karma__.start(), right ? Maybe the adapter could timeout if you (user/developer) don't call __karma__.start(), not sure what else we can do about it.

@agsha can you make sure, you call __karma__.start() after loading files with require ?

@kimjoar
Copy link
Contributor

kimjoar commented Apr 21, 2013

@vojtajina Without backticks, __karma__ comes out as karma (i.e. in bold) when using Markdown :)

@vojtajina
Copy link
Contributor

@kjbekkelund thanks, I fixed the comment.

@vojtajina
Copy link
Contributor

@junaidabidi You are running e2e tests, so your problem is more likely something completely different, please create a separate issue.

For those using Jasmine, I looked into @sammla 's project and found out something...
short story, you can "fix it" by doing:
jasmine.DEFAULT_UPDATE_INTERVAL = 0;

Jasmine does setTimeout in this interval, so that the browser can "breath" - eg. if you are using html reporter, without this, it would only show the results at the end. Because this setTimeout, Jasmine gives the browser a chance to render.

For some reason, sometimes this setTimeout never fires back. I have no idea why. Don't have time to dig into it now, but would be super awesome, if somebody could look into it. It's this code https://github.com/karma-runner/karma/blob/stable/adapter/lib/jasmine.js#L2164-L2168 where Jasmine does setTimeout to schedule running next specs (after browser renders). For some reason, this setTimeout is never fired and therefore it hangs (sometimes it does fire).

Setting jasmine.DEFAULT_UPDATE_INTERVAL = 0 means disabling this feature. So it's kind of workaround, not a solution, but it should at least help you to get unstuck...

@johnkors
Copy link

johnkors commented May 1, 2013

+1. Tests executes normally when I remove Require. Win 8 + Node v.0.10.5 + karma v.0.9.2

@vojtajina
Copy link
Contributor

@johnkors does setting jasmine.DEFAULT_UPDATE_INTERVAL = 0; help ?

@mohanraj-r
Copy link

@vojtajina jasmine.DEFAULT_UPDATE_INTERVAL = 0; does help (after commenting out REQUIRE*). Thanks.

fyi: I am including the test spec js and all libraries required in files section. Being new to node and js (and trying to convert from JSTD), wish that using REQUIRE was easier - without creating a seperate main file and going through all the steps as listed in kjbekkelund/karma-requirejs · GitHub.

@vojtajina
Copy link
Contributor

@mohanraj-r I think we could simplify the init process for require, but having karma init to generate the test-main.js file. Anybody interested in making it happen ?

@v1bh0r
Copy link

v1bh0r commented Aug 27, 2013

I had created an app using the angular-generator that comes with yeoman.
AutoWatch was failing to re-run the tests because of the error reported in this issue.
I was able to resolve it by commenting out the port number and going by the defaults:
Here's what I had in my karma.conf.js file:
// web server port
port: 8080

@andrew-luhring
Copy link

@vojtajina

https://github.com/karma-runner/karma/blob/stable/adapter/lib/jasmine.js#L2164-L2168

"^ this is not the webpage you are looking for"

did anyone find a solution to this? I'm using mocha and getting the same error.

module.exports = function(config) {
  config.set({

    basePath: './',
    frameworks: ['requirejs', 'jquery', 'mocha', 'expect'],
    plugins: ['karma-*', 'jquery'],
      files: [
          "public/stylesheets/style.css",
          "public/javascripts/lib/jquery.js",
          "public/javascripts/script.js"
      ],
//declaring jquery 3 times. i know. I don't know why it's necessary but it is for some reason.
    exclude: [
        'node_modules/*',
        '**/*_ignore.js*'
    ],
    // possible values: 'dots', 'progress', 'junit', 'growl', 'coverage'
    reporters: ['progress, unicorn'],
    port: 9876,
    colors: true,
    // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
    logLevel: config.LOG_INFO,
    autoWatch: true,
    // - Chrome, PhantomJS
    browsers: [],
    captureTimeout: 60000,

    singleRun: false
  });
};

@vojtajina
Copy link
Contributor

@andrew-luhring Did you check the browser? Is there any error in the console? What is the "jquery" plugin? I dont' think that's a Karma plugin....

@mkolodny
Copy link

In case this helps anyone, my issue was with my files property in my karma.conf.js. I had {pattern: 'test/unit/*.js', included: false} before 'test/unit/main.js', so my main.js file wasn't being included.

Changing the pattern to {pattern: 'test/unit/*Spec.js', included: false} fixed my issue. I didn't need to set jasmine.DEFAULT_UPDATE_INTERVAL = 0;.

@andrew-luhring
Copy link

@vojtajina the jquery plugin was me trying to include jquery.
I don't think there were any errors in the browser console.
my solution ended up being to not use requirejs.
One thing I was trying to do at some point was to configure mocha to use the nyancat reporter... Never got that working. I remember reading somewhere in the code that theres a way you can pass arguments to mocha but never got it working.

@andrewluetgers
Copy link

I ran into this problem the solution for me was adding port and runner port values to karma.unit in the Gruntfile.js solution was found here ngbp/ngbp#37 (comment)

@vojtajina
Copy link
Contributor

@andrew-luhring I don't see any "test-main.js" or something in your config. With require the tests has to be started asynchronously, after require is done with loading all the files. That's why you have to start karma through __karma__.start(). See the e2e example https://github.com/karma-runner/karma/blob/master/test/e2e/requirejs/main.js

@andrewluetgers I really don't think specifying port in Gruntfile can help with anything mentioned in this issue...

Anyway, this issue is becoming a mess. I'm closing it. Please open a new one if you still experiencing any of those issues or have any ideas how to improve it...

Here's what we are going to do in order to fix these issues / make it simpler:

@andrewluetgers
Copy link

@vojtajina i made a video demonstrating the issue for you
https://www.youtube.com/watch?v=4Y5tRkhmiN0&feature=youtu.be

@ghost
Copy link

ghost commented Mar 20, 2014

I've just been bit by this, and can reliably reproduce or not by having more than one testSpec.js file. That is, if all my tests are in a single file, it works fine. If I add a second fooSpec.js file in the watched directory, even if it contains no tests, the browser hangs always after first run.

I very very highly suspect this is related to RequireJS. It took me a full 2 days to get Karma to work at all -- asked a lot of (unanswered) questions on SO, tried to get QUnit to work, eventually gave up, pounded my head for a while and managed to get Mocha running, migrated some of my QUnit tests to Mocha, was very happy. Then I decided it's time to split the monster test file back into per-module test files. And discovered this bug. Which is, obviously, a VERY SERIOUS bug.

If I can add info to assist in resolving, let me know. I'm not in a good mood at this point about Karma, but maybe AMD is outside the normal usage? Unfortunately, for many like me, removing dependencies on AMD is not an option, and certainly not just to support a test runner.

@ghost
Copy link

ghost commented Mar 20, 2014

LOL @andrewluetgers nice vid :)

Has this issue been considered resolved or what? Because it is not. And its a bit of a showstopper. Karma is awesome when it works, I'm glad I spent 2 days pulling my hair out to get it to work. But that awesomeness is predicated heavily on it actually working. I'm wondering why this thread died 2 months ago...

@ghost
Copy link

ghost commented Mar 20, 2014

Not sure if anyone reads closed issues, but updating with notes as I progress here:

I have diffed the commits to my project between when this problem never occurred and when it always occurs. (Unfortunately it seems to always occur regardless of how many files are open, though that was definitely happening earlier.) I can switch between these commits and its extremely reproducible. What's frustrating is that the main activity in the broken commit was moving files around so its hard to see what changed, but I have confirmed that both karma.conf.js and test-main.js (setting up RequireJS) are binary identical between the two commits. Literally all other changes were to my project source and the unit tests.

One thing I ruled out as the issue was that I added 'use strict' at file level to all my source. Not thinking that would be the problem, but very few actual code changes went into the commit.

I paused the test runner in Chrome DevTools, since it says "executing" indefinitely. After a brief moment (not instantly) it paused at a websocket connection, but I could't discern any useful information about this. I suppose it confirms that the browser was not in fact "executing" anything that was causing it to hang, but as Vojta said, it may have been waiting indefinitely for something to indicate to continue.

Inspecting my tests next, but it's worth pointing out, this problem occurs even with all tests commented out.

@ghost
Copy link

ghost commented Mar 20, 2014

I rolled back to last good commit, and bit by bit reconstructed every change I made -- all just moving files around. The problem never re-emerged. It's a mystery. If I encounter it again I'll post a new issue with more details.

@dcrockwell
Copy link

In case it helps anybody, I've isolated this scenario down to a single call in my own test setup:

element.should.eql('anything can go here and cause a freeze');

It seems that should.js is not playing well with dom elements in Chrome and Safari.

@randomor
Copy link

Same issue, tried Chrome and Safari. In the browser it displays the perpetual "xx is executing", and in the terminal it says: "Delaying execution, these browsers are not ready: Safari 7.0.4 (Mac OS X 10.9.3)". I installed Jasmine and Karma and upgraded Node just today. Karma version: 0.12.16.

@dopatraman
Copy link

Please keep this issue open, I'm also running into the same problem:

My config:

// Karma configuration
// Generated on Fri Oct 17 2014 13:15:42 GMT-0400 (EDT)

module.exports = function(config) {
  config.set({

    // base path, that will be used to resolve files and exclude
    basePath: './',


    // frameworks to use
    frameworks: ['jasmine', 'requirejs'],


    // list of files / patterns to load in the browser
    files: [
      'vendor/angular/angular.js',
      {pattern: 'build/src/**/*.js', included: false},
      {pattern: 'src/**/*.spec.js', included: false}
    ],


    // list of files to exclude
    exclude: [
      '**/*.swp',
      '**/*.html',
      '**/*.json'
    ],

    urlRoot: '/',

    // test results reporter to use
    // possible values: 'dots', 'progress', 'junit', 'growl', 'coverage'
    reporters: ['progress'],


    // web server port
    port: 9876,


    // enable / disable colors in the output (reporters and logs)
    colors: true,


    // level of logging
    // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
    logLevel: config.LOG_INFO,


    // enable / disable watching file and executing tests whenever any file changes
    autoWatch: false,


    // Start these browsers, currently available:
    // - Chrome
    // - ChromeCanary
    // - Firefox
    // - Opera
    // - Safari (only Mac)
    // - PhantomJS
    // - IE (only Windows)
    browsers: ['Chrome', 'Firefox', 'PhantomJS'],


    // If browser does not capture in given timeout [ms], kill it
    captureTimeout: 60000,


    // Continuous Integration mode
    // if true, it capture browsers, run tests and exit
    singleRun: true
  });
};

When I run `karma start karma.conf.js --single-run`` the server waits for connections:

INFO [karma]: Karma v0.9.8 server started at http://localhost:9876/
INFO [launcher]: Starting browser Chrome
INFO [launcher]: Starting browser Firefox
INFO [launcher]: Starting browser PhantomJS
INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket id 0w5LNk2KhJPpKC0tfxXe
INFO [Firefox 27.0.0 (Mac OS X 10.9)]: Connected on socket id Gvllo4ZtCVTQdE56fxXf
INFO [Chrome 38.0.2125 (Mac OS X 10.9.2)]: Connected on socket id gSgUhY-rLVHQ82isfxXg

If I check the console in the browser windows that open (Chrome and FF), there are no errors.

THEN, when I run karma run I get

INFO [karma]: Delaying execution, these browsers are not ready: PhantomJS 1.9.7 (Mac OS X), Firefox 27.0.0 (Mac OS X 10.9), Chrome 38.0.2125 (Mac OS X 10.9.2)

What is going on? Why cant I run my tests?

@keithharvey
Copy link

Found a fix for my own encounter with this issue (I am also using coffeescript). Switching my spec to use -> instead of => did it

@ghost
Copy link

ghost commented Apr 22, 2016

Hmmm also running into this problem with unit tests written in TypeScript.

Versions:

karma: 0.13.22
PhantomJS: 2.1.1
npm: 3.3.6
node: 5.0.0

I'll play around with the configuration to see if I can get it to work. Karma runs fine with singleRun set to true. It's a great tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests