SDK/Debugger version: v. 0.3.4/0.1.6

Eclipse version: NONE; I'm trying to build my own Java frontend

Google Chrome/V8 Embedder + version: Chromium 17.0.963.79 (Developer Build 125985) Ubuntu 11.10

Java: 1.6.0_26; Java HotSpot(TM) 64-Bit Server VM 20.1-b02 System: Linux version 3.0.0-16-generic running on amd64; UTF-8; en_NZ (nb)

I'm writing my own frontend for Remote Webkit Debugger in Chrome/ium using your SDK. It works well but I have following problem: I can establish connection from my Java client to a Chromium browser tab and can debug it; when the tab is closed in the browser the SDK throws java.net.SocketException: Broken pipe (see attachment for full stacktrace). I checked your Javadoc and everything I could but it looks to me like a problem in the SDK. Attached is also very simplified Java test case. To use it:

• start browser, eg. "chromium-browser --remote-debugging-port=9222 http://google.com"

• run the Java file

• [optional - just to verify debugging connection was established] reload the page in the browser to see Java program dump all the scripts referenced by the page in browser

• close chromium -> always results into attached socket exception

Thanks.

I don't think SDK throws this exception. It simply prints it.

So this looks more like a cosmetic issue to me. Please confirm it's cosmetic in your case too.

I guess we can try to stop SDK from printing it.

You are right, exception is not thrown but logged as SEVERE:

AbstractWsConnection.java:114 LOGGER.log(Level.SEVERE, "Connection read failure", e);

My application has a global handler which displays exceptions logged with this severity to users so that users can report them back to us and we can fix them. The problem here is that I have no way of "catching" this logger event. I could perhaps create a filter and ignore all logger events from Hybi00WsConnection class but I'm not very keen on that - what if there is a real exception which is important to user?

I'm not sure what's the best resolution. Ideally the SDK would correctly interpret this state as "browser was closed" and fire appropriate SDK event and not log this exception as it is not a problem. Alternatively your thread could remember the problem and throw an exception (instead of logging it) next time when an SDK API call is made which depends on thread being in a healthy state.

What do you think? I will look into filtering it out for now on my side. Thanks!

Patch is proposed: https://chromiumcodereview.appspot.com/9959080/

INFO message is still planned to be logged, as currently Chrome incorrectly skips "close" protocol frame and simply silently closes.

Fixed in HEAD

Fixed in 0.3.6