-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Frequent disconnecting while debugging in single runs #2532
Comments
Here's the output of the above, but with
|
If it helps, if you set autoWatch to true and singleRun to false, you could click the debug button in the browser that opens up (cannot use PhantomJS in this case I believe), and set a breakpoint to debug the test. Not sure if it would help you work around this case though with PhantomJS. |
@wesleycho I appreciate the tip (didn't know |
@wesleycho @isiahmeadows Is this same as issue mentioned in #2447 ? |
@dignifiedquire I believe this will be fixed by adding a big numerical value for But, in order to be used by @isiahmeadows, we might need to release a version. @isiahmeadows Is it possible for you to check directly from master? Do you require a release? |
@vivganes you can always specify to consume a specific commit with npm. Karma doesn't have a build process, so it wouldn't depend on anything special being done. |
I'd strongly prefer a release, but I can at least try `master` or whatever
you all use for nightlies, until it's released (I control it exclusively,
but it's for a decently sized testing framework). It's basically blocking
me from debugging an unusual, obscure bug in a dependency that won't easily
reproduce, something I'm *not* looking forward to.
|
Expected behaviour
No disconnection while idling in the debugger
Actual behaviour
Wait in the debugger for more than 2 seconds, and the connection is dropped
Environment Details
karma --version
): 1.3.0karma.config.js
fileSteps to reproduce the behaviour
npm i karma karma-mocha karma-phantomjs-launcher mocha
)karma start --single-run
It then proceeds to disconnect, ignoring the astronomically high
browserNoActivityTimeout
. I suspect part of it is because the main loop is blocked, ensuring the websocket doesn't get any data. Sending the test data from a web worker should alleviate the problem, since it's no longer blocked by the debugger on the main thread. (Long running tests would also benefit from this.)On the other hand, it's odd that the timeout is even being ignored at all. It's extremely difficult to debug failing PhantomJS tests when this is going on (and it's very specific to that platform).
The text was updated successfully, but these errors were encountered: