gorhill
https://github.com/gorhill/chromium-websocket-wrapper/issues/3
Details of the issue: https://github.com/AdguardTeam/AdguardBrowserExtension/issues/307
Take a look at "Event" properties overriding. Pretty ugly, but I have not found a better way.
Sorry, I haven't had time to look at the code yet -- I will try to do so soon.
FYI @kzar, you probably want to test that site also for https://issues.adblockplus.org/ticket/1727.
@gorhill Thanks for the heads up, I just checked and luckily the implementation for #1727 doesn't have the same problem.
@gorhill JFYI, here is @kzar implementation: https://codereview.adblockplus.org/29347034/diff/29349640/include.preload.js
The downside is that it does not prevent the actual WS connection. On the other hand it is very simple, no vodoo magic with events and such, and it works. Nice:)
As of a few minutes ago it has landed in our repository too :+1: (FWIW it does prevent the WS connection, for me at least. I tested with WireShark to make sure no connections were leaked, not even the initial HTTP upgrade request. It's true, as discussed in the code review, that this could be a race condition or change with browser implementation however.)
I guess for @gorhill's approach it won't be that good as he sends a web request to detect if WS connection should be blocked or not. But in our case with relying on Chrome messaging it is good enough indeed.
not even the initial HTTP upgrade request
Have you tested it with WS or WSS? I mean the difference is pretty huge, SSL handshake takes at least 20-30ms which is more than enough for checking and closing it before upgrade request is sent.
IIRC HTTP because I couldn't get the test to work with HTTPS, but I can't remember for sure.