chromedriver closes Chrome's dev tools unexpectedly

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run a scenario involving Selenium WebDriver (2.35) and chromedriver 2.2
2. While scenario is running, open Chrome's dev tools in the chromedriver 
driven browser
3. wait a bit, after a WebDriver command is issued, the dev tools window is 
closed

What version of the product are you using? On what operating system?
ChromeDriver = 2.2 (Homebrew also reports 26.0.1383.0)
Chrome = 29.0.1547.57
OS = OSX 10.8.4

Original issue reported on code.google.com by mgr...@rallydev.com on 26 Aug 2013 at 8:20

[GoogleCodeExporter]

This is expected behavior. ChromeDriver uses Chrome's debugging facilities, 
which only allows one client at a time. What is your use case? Are you 
debugging a test, or just interested in what's happening?

Original comment by kkania@chromium.org on 26 Aug 2013 at 10:41

• Changed state: NeedsClarification

[GoogleCodeExporter]

Yes, generally we are debugging a test. Before chromedriver 2.2, the dev tools 
were never an issue. They stayed open indefinitely and only closed when we 
closed them.

Now with 2.2, we will start a webdriver driven test, open the dev tools 
manually, start debugging the test, and part way through the test the dev tools 
close. This mostly happens when we set a breakpoint for a future part of the 
test, and press play expecting the breakpoint to get hit. But instead the dev 
tools close, not letting us investigate that part of the test.

Original comment by mgr...@rallydev.com on 26 Aug 2013 at 11:00

[GoogleCodeExporter]

Before chromedriver 2, chromedriver used an automation api that is no longer 
supported.

We are interested in improving the debugging situation, but this will probably 
not be soon. Thanks for describing your use case. We haven't had much demand 
for this feature yet.

Original comment by kkania@chromium.org on 26 Aug 2013 at 11:56

• Changed state: Accepted

[GoogleCodeExporter]

Here is a StackOverflow question with the same problem: 
http://stackoverflow.com/questions/18420769/chrome-developer-tools-closes-instan
tly-when-attempting-to-debug-webdriver-e2e-t

Original comment by matt.e.g...@gmail.com on 27 Aug 2013 at 1:42

[GoogleCodeExporter]

We are using the dev tools to get the request time from the Network tab in our 
cases but now we can't. Hope the future drivers can support using dev tools in 
users' cases again.

Original comment by QiMeng...@gmail.com on 4 Sep 2013 at 10:11

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm sometimes (perhaps not very often, but sometimes) using Dev Tools to place 
Javascript breakpoints, but when the dev tools window is automatically closed, 
the Javascript breakpoints become inactive.

A workaround for the Dev Tools-window-closing-issue is described here: 
https://code.google.com/p/chromedriver/wiki/TroubleshootingAndSupport#The_window
_keeps_closing_during_the_test  
but it doesn't handle this scenario with Javascript breakpoints.

(Reposting comment, fixed a typo)

Original comment by kajmagnu...@gmail.com on 4 Sep 2013 at 10:50

[GoogleCodeExporter]

Without access to devtools, it is very hard to debug a failing test as it runs. 
A lot of times, tests fail because of the automation itself and one needs to 
throw in debugger statements or console logs to investigate. Please bring back 
devtools, thanks.

Original comment by Drey...@gmail.com on 4 Sep 2013 at 9:04

[GoogleCodeExporter]

+1 to be able to put breakpoints to debug failing tests.

Original comment by dlaze...@gmail.com on 11 Sep 2013 at 7:15

[GoogleCodeExporter]

We have a CI server which is failing our tests and the lack of DevTools is 
making it impossible to debug. The advice on the wiki is to pause my test run 
is difficult in practice.

Original comment by scound...@gmail.com on 19 Sep 2013 at 2:58

[GoogleCodeExporter]

+1, I end up switching to Firefox to debug my tests now

Original comment by bdavid...@rallydev.com on 25 Sep 2013 at 5:20

[GoogleCodeExporter]

Original comment by kkania@chromium.org on 30 Sep 2013 at 10:52

• Changed state: Verified

[GoogleCodeExporter]

Wouldn't it help to implement a debugging proxy which would aggregate 
requests/responses from one or more debugging clients?

Original comment by lu...@fryc.eu on 14 Oct 2013 at 6:00

[GoogleCodeExporter]

Issue 515 has been merged into this issue.

Original comment by samu...@chromium.org on 25 Oct 2013 at 7:23

[GoogleCodeExporter]

did any one get any workaround for this.

Original comment by sunalps2...@gmail.com on 19 Feb 2014 at 10:33

[GoogleCodeExporter]

I am seeing devtools working in chromedriver 2.6 on Windows. They are a very 
wonky when tests are still being run but once the selenium client detaches they 
are usable.

Original comment by scound...@gmail.com on 19 Feb 2014 at 10:40

[GoogleCodeExporter]

It's odd that if the chrome dev tools are open in a different window, they will 
close, but if they are open in a pane, webdriver will just throw an error 
(something like 'Runtime.evaluate threw exception: TypeError: Cannot read 
property 'click' of null'). Could the thrown error at least be more useful?

Original comment by ral...@google.com on 21 Jun 2014 at 1:05

[GoogleCodeExporter]

if windowed DevTool get's closed during test, then why does pane'ed devtool 
raise a exception rather than being closed as well?

Original comment by Krishna....@gmail.com on 19 Sep 2014 at 6:17

[GoogleCodeExporter]

I too used to occasionally use dev tools whilst debugging, to watch for console 
messages as they happen particularly if the test is waiting for an event 
(element appearing on screen for example) and that event is not happening, I 
want to look at the console so that I can see what the app is doing/trying to 
do, in order to figure out why the test is not progressing.  I can log dump in 
my test but its hard to predict where you might need to do that.

When a test fails outright, I sleep (while still connected) giving me chance to 
use dev tools to debug why it might have failed.

Original comment by Austin.France on 2 Dec 2014 at 5:49

[GoogleCodeExporter]

Another use case is debugging network comms (AJAX) which you can't do 
retrospectively because the network tab has to be open while the network 
activity is occurring in order to be able to record it.

Obviously if I can manually reproduce the problem encountered, then that is not 
an issue, but in many cases, it only happens during the automated regression 
test.  

I am trying to debug what appears to be network related issue now with a 
regression test, and finding it almost impossible.  Connecting to the dev tools 
after the event I can see a cache miss error in the console log around the time 
the test fails, but I can't debug that request because it has already happened. 
 I can't set a breakpoint to debug that test either because the dev tools won't 
stay open.   

I can't reproduce it manually because it seems to only happen during the set of 
circumstances the regression tests create (and to try and reproduce that 
manually would be very difficult).

Original comment by Austin.France on 2 Dec 2014 at 6:00

[GoogleCodeExporter]

Original comment by samu...@chromium.org on 21 Feb 2015 at 12:19

• Changed state: Untriaged