browser disconnection when debugging tests

[segrey]

Reproduced with karma@0.9.3

1. Start karma server in the console.
2. Capture Chrome browser.
3. Run tests using karma run command.
4. Switch to the browser and open Developer Tools. Open Sources tab and place a breakpoint somewhere in a spec or source under test file.
5. Run tests again using karma run command.
6. Switch to the browser. The breakpoint is hit as expected.
7. Do nothing for a minute or two.
8. karma run command exits unexpectedly.
   Karma server log:

...
DEBUG [karma]: Execution (fired by runner)
DEBUG [karma]: Refreshing all the files / patterns
DEBUG [karma]: List of files has changed, trying to execute
DEBUG [karma]: All browsers are ready, executing
DEBUG [watcher]: Resolved files:
    /home/segrey/stuff/temp/1/node_modules/karma-jasmine/lib/jasmine.js
    /home/segrey/stuff/temp/1/node_modules/karma-jasmine/lib/adapter.js
    /home/segrey/stuff/sample-js-tests/jasmine/evanhahn/src/helloWorld.js
    /home/segrey/stuff/sample-js-tests/jasmine/evanhahn/src/person.js
    /home/segrey/stuff/sample-js-tests/jasmine/evanhahn/spec/helloWorldSpec.js
    /home/segrey/stuff/sample-js-tests/jasmine/evanhahn/spec/personSpec.js
DEBUG [web server]: serving: /home/segrey/stuff/temp/1/node_modules/karma/static/context.html
Chrome 28.0.1500 (Linux): Executed 0 of 7 DISCONNECTED (1 min 12.787 secs / 0 secs)
WARN [Chrome 28.0.1500 (Linux)]: Disconnected

[segrey]

If a coverage is configured, things are even worse.
Karma server log:

...
DEBUG [web server]: serving: /home/segrey/stuff/temp/1/node_modules/karma/static/context.html
Chrome 28.0.1500 (Linux): Executed 0 of 7 DISCONNECTED (1 min 12.787 secs / 0 secs)
ERROR [karma]: [TypeError: Cannot read property 'coverage' of undefined]
TypeError: Cannot read property 'coverage' of undefined
    at onBrowserComplete (/home/segrey/stuff/temp/1/node_modules/karma-coverage/lib/reporter.js:66:21)
    at EventEmitter.emit (events.js:117:20)
    at onDisconnect (/home/segrey/stuff/temp/1/node_modules/karma/lib/browser.js:84:15)
    at Socket.EventEmitter.emit [as $emit] (events.js:95:17)
    at Socket.onDisconnect (/home/segrey/stuff/temp/1/node_modules/karma/node_modules/socket.io/lib/socket.js:153:10)
    at SocketNamespace.handleDisconnect (/home/segrey/stuff/temp/1/node_modules/karma/node_modules/socket.io/lib/namespace.js:229:46)
    at Manager.onClientDisconnect (/home/segrey/stuff/temp/1/node_modules/karma/node_modules/socket.io/lib/manager.js:501:29)
    at WebSocket.Transport.end (/home/segrey/stuff/temp/1/node_modules/karma/node_modules/socket.io/lib/transport.js:467:20)
    at null._onTimeout (/home/segrey/stuff/temp/1/node_modules/karma/node_modules/socket.io/lib/transport.js:268:12)
    at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)
DEBUG [launcher]: Disconnecting all browsers

After that karma server process is terminated.

[vojtajina]

As for the first issue, I'm not sure what the exact reason is, but there might be some timeout and I assume the browser kills the websocket connection. The debugger pauses all JS execution. This is not a high priority for me, you should use http://localhost:9876/debug.html for debugging.

Ad second issue (with coverage), I fixed that:
karma-runner/karma-coverage@5eca488

[segrey]

If http://localhost:9876/debug.html is used for debugging, then one more page needs to be opened.
WebStorm can open this page automatically in the right browser. What I worry about is that this complication is exposed to our users. I mean it's easier to manage one Karma page than two pages.
I agree that it isn't a high priority for Karma core.
It's caused by not sending heartbeat socket.io event by a browser, thus this browser is considered to be disconnected.
I'll look into the issue. In case of "impossible to fix", WebStorm will use http://localhost:9876/debug.html.

[vojtajina]

Maybe I'm missing something, but I don't think we have control over this. Debugger just pauses ANY JS execution and there's probably some browser timeout, that cancels the requests (even websocket). I'm not totally positive with the details though.

[segrey]

Yes, you're right about the cause. Unfortunately, I still don't have a good solution for this issue. For now, WebStorm Karma integration uses http://localhost:9876/debug.html for tests debugging. WebStorm with updated Karma plugin will be available in the next WebStorm 7 EAP, that is planned for today (a new blog post will be added in the http://blog.jetbrains.com/webstorm/).
Nevertheless debugging is working as expected and there are no browser disconnects, this approach has downsides besides opening one more page in browser:

1. There is no test tree shown when tests are debugged. That's so, because the test tree is built using messages sent by JS reporter. When tests are executed in http://localhost:9876/debug.html, test results aren't reported to the Karma server:
   

2. The debug session never stops, because it's unclear when tests are finished.
   Previously, with http://localhost:9876, when tests debugging was requested, "karma run" process was started, and it initialized tests running in http://localhost:9876. Debugging session was closed on "karma run" process termination.
   Now, with http://localhost:9876/debug.html, when tests debugging is requested, "karma run" isn't started, because http://localhost:9876 isn't used for debugging. So, it's unclear when debug session is finished.
   So the Stop button is always active.

A possible solution for the second issue is to send some special message to console.log in http://localhost:9876/debug.html. WebStorm will check all messages sent to console.log (it can do this magic stuff when browser tab is debugged).
Something like console.log('all tests finished') - just tell me what the message is and I'll fix Karma plugin.

Sorry for the long comment. I don't lose hope that it'd be possible to debug tests in http://localhost:9876 flawlessly. That would be cool. BTW, JsTestDriver has no such problem with browser disconnect, so tests debugging is a bit easier to use there.
I'll update this issue if I find something good.

[vojtajina]

@segrey Maybe you can try different transports (instead of websocket, html-polling or jsonp-polling might be less sensitive to paused debugger). We can also fiddle with socket.io configuration, maybe we can set some longer timeout.