Karma issue with browsers disconnecting with network delay

[bstrauch]

I'm currently not able to submit a PR to fix this issue due to restrictions with the Google CLA.

Expected behaviour

Karma waits for the browser to connect to the socket.

Actual behaviour

Depending on the network delay of connecting to a socket, the socket.io server that a browser is connected to will disconnect causing any Karma reporter to fail, but the tests will still execute in Karma.

Older versions of Karma such as 2.0.5 used an older version of socket.io. The pingTimeout value in socket.io used to default to 60 seconds and is currently 5 seconds. Any browser that does not successfully connect to the socket.io server within 5 seconds will disconnected from a "pingTimeout error."

Environment Details

• Karma version (output of karma --version): Issue occurs with Karma version >= 3.0.0

Steps to reproduce the behaviour

1. Increase your network delay to be greater than 5 seconds when connecting to a browser.

Solution

This can be solved by exposing additional config options in your own Karma config file. This would require adding a pingTimeout variable in the Config constructor in /lib/config.js and then adding that variable to the object passed into the socket.io server located in /lib/server.js.

This is similar to how the transports and forceJSONP options get exposed and are modifiable via the karma.config.js file.

This extra option allows a user to increase the pingTimeout value for the socket.io server via their own karma.config.js file to prevent their browsers from disconnecting when there is a large network delay.

https://socket.io/docs/server-api/
http://karma-runner.github.io/4.0/config/configuration-file.html

[johnjbarton]

Why don't we just set the default back to 60s?

[bstrauch]

You could set the default back to 60s by adding pingTimeout: 60000 to the options object passed into the socket.io server. But making it a config option would allow people to modify it however they need. Most users seem to be fine with the current 5s pingTimeout value since the issue isn't very common.

[johnjbarton]

@bstrauch Please review

[bstrauch]

Looks good to me. Thanks!