from websock.js > // Check for full binary type support in WebSockets > // TODO: this sucks, the property should exist on the prototype > // but it does not. > try { > if (bt && ('binaryType' in (new WebSocket("ws://localhost:17523")))) { > Util.Info("Detected binaryType support in WebSockets"); > wsbt = true; > } > } catch (exc) { > // Just ignore failed test localhost connections > } chrome 36 says: > [blocked] The page at 'https://localhost:300/main/agent?launch_vnc=1 > &display=1&vncpassword=asdfasdfasdfasdfasdfasdfasdf' was loaded over > HTTPS, but ran insecure content from 'ws://localhost:17523/': this > content should also be loaded over HTTPS.
Fixed with vendordrop in commit 29268.
RFS.js: init_vars() calls Websock.js:init() without arguments which makes stuff break.
(In reply to comment #2) > RFS.js: init_vars() calls Websock.js:init() without > arguments which makes stuff break. 29486.
Update in r29487.
Now when testing nighly build with commit xxx another issue is raised: ERROR: WebSocket connection to 'wss://./' failed: Error in connection establishment: net::ERR_NAME_NOT_RESOLVED And I wont get further to a vnc connection when using chrome 38.0.2125.101.
(In reply to comment #5) > And I wont get further to a vnc connection when using chrome 38.0.2125.101. I had a breakpoint preventing me to login, it works as expected but still logs an error to console.
(In reply to comment #5) > ERROR: WebSocket connection to 'wss://./' failed: Error in connection > establishment: net::ERR_NAME_NOT_RESOLVED This is due to peculiarities in Chrome.... This test works in most browsers: 'binaryType' in WebSocket.prototype But in Chrome we need to check: (new WebSocket(ws_schema + '://.').binaryType And Chrome evaluates the url but properly creates the object despite any errors in the url, there is no way to get rid of this message. The error message has no effect.
