Can't connect to Chrome tab on Windows

[jryans]

Moved from https://bugzilla.mozilla.org/show_bug.cgi?id=1119393.

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2267.0 Safari/537.36

Steps to reproduce:

Tried to use Valence from Firefox Developer Edition (36.0a2) on Chrome (41.0.2667.0 dev-m 64bit)

OS:
Windows 8.1 Pro WMC 64bit

Actual results:

But got Error as "Chrome Desktop not found".
Started Chrome with the following flags:
--remote-debugging-port=9222
--no-first-run
--no-default-browser-check

Expected results:

Could have started the debugging and connected to the Chrome Browser

[jryans]

I tried to reproduce this. I was able to connect to Chrome and list tabs, but saw errors trying to open the toolbox for a tab:

"<<<<<< Connecting to ws://localhost:9222/devtools/page/5288CEA5-622B-46DE-82E6-16DDB840F5DC..." rpc.js:22
Firefox can't establish a connection to the server at ws://localhost:9222/devtools/page/5288CEA5-622B-46DE-82E6-16DDB840F5DC. rpc.js:24:0
">>>>>> Web socket closed: 1006/"

[jryans]

For the original reporter, what version of the Valence / Firefox Tools Adapters add-on do you have in Firefox (check about:addons)? Did you have a web site open in a tab in Chrome before trying to connect to it?

[decode-dev]

I am using Firefox Developer Edition (37.0a2).
The screenshot of the error using the Browser Console form Firefox Dev. Browser
Left:
Chrome Browser (Pages opened before using Valence) with the following flags
--remote-debugging-port=9222
--no-first-run
--no-default-browser-check
Right:
Browser Console

[callahad]

TL;DR: As far as I can tell, Chrome 41 (beta, dev) and 42 (canary) don't work with Valence. Chrome 40 (stable) does.

I'm able to reproduce this on OS X 10.10.1 with fxdt-adapters version 0.2.4 targeting Chrome 41.0.2272.12 dev (64-bit), Chrome 41.0.2272.17 beta (64-bit), and Chrome 42.0.2288.2 canary (64-bit) from both Nightly 38.0a1 (2015-01-26) and DevEdition 37.0a2 (2015-01-26).

Chrome 40.0.2214.93 (64-bit) appears to work.

[past]

There appears to be some incompatibility in the WebSocket connection, as it returns CLOSE_ABNORMAL as the status code. I'll dig into the DOM code next to find out more.

[past]

This is the actual cause:

WebSocketChannel::HandleExtensions: HTTP permessage-deflate extension negotiated unknown parameter server_max_window_bits=15; client_max_window_bits=15

Obtained by increasing the platform runtime logging with:

export NSPR_LOG_MODULES=nsWebSocket:5

[past]

It appears that we don't currently implement all of the per message compression extensions specified in this draft:

http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-19

However, there is probably a bug in the Chrome side where it sends these options even though we haven't asked for them. In any case we will have to either implement the extensions or work around the Chrome bug in the platform.

[past]

Bug 1137008 is about handling this Chrome behavior gracefully.