Issue 5027 - Use updated webRequest API for WebSocket blocking

lib/requestBlocker.js

Index: lib/requestBlocker.js
===================================================================
--- a/lib/requestBlocker.js
+++ b/lib/requestBlocker.js
@@ -147,17 +147,20 @@
 FilterNotifier.on("subscription.removed", onFilterChange);
 FilterNotifier.on("subscription.updated", onFilterChange);
 FilterNotifier.on("subscription.disabled", arg => onFilterChange(arg, true));
 FilterNotifier.on("filter.added", onFilterChange);
 FilterNotifier.on("filter.removed", onFilterChange);
 FilterNotifier.on("filter.disabled", arg => onFilterChange(arg, true));
 FilterNotifier.on("load", onFilterChange);
 
-port.on("request.websocket", (msg, sender) =>
+if ("WEBSOCKET" in chrome.webRequest.ResourceType)

[Sebastian Noack, 2017/03/27 12:13:36]

It seems this check should follow the same logic as the check in lib/csp.js:

  if (!("WEBSOCKET" in chrome.webRequest.ResourceType))

Otherwise, it seems, we redundantly process the WebSocket connections reported
by the WebSocket wrapper workaround when WebSockets are already handled by the
webRequest API, and vice-versa if WebSockets cannot be blocked by the webRequest
API (on Chrome <58) the WebSocket wrapper we rely on never gets a response.

[Jon Sonesen, 2017/03/27 12:35:23]

Yeah, I see that was an oversight. For some reason I had that logic inverted
here thinking we still wanted to wrap websocket connections even if websocket
support exists and csp injection is disabled. Sorry.

 {
-  return ext.webRequest.onBeforeRequest._dispatch(
-    new URL(msg.url),
-    "WEBSOCKET",
-    sender.page,
-    sender.frame
-  ).indexOf(false) != -1;
-});
+  port.on("request.websocket", (msg, sender) =>
+  {
+    return ext.webRequest.onBeforeRequest._dispatch(
+      new URL(msg.url),
+      "WEBSOCKET",
+      sender.page,
+      sender.frame
+    ).indexOf(false) != -1;
+  });
+}