Enable websocket filtering via SubresourceFilter

chrome/test/data/subresource_filter/websocket_connection.js

Index: chrome/test/data/subresource_filter/websocket_connection.js
diff --git a/chrome/test/data/subresource_filter/websocket_connection.js b/chrome/test/data/subresource_filter/websocket_connection.js
new file mode 100644
index 0000000000000000000000000000000000000000..4d5db4cb67fb48281f0c2b8abd3eb0bae616ba03
--- /dev/null
+++ b/chrome/test/data/subresource_filter/websocket_connection.js
@@ -0,0 +1,32 @@
+// Note: This JS can run either in a worker or as a script in the main document
+// context.
+function connectWebSocket(url, inWorker) {
+  function messageMainContext(data) {
+    if (inWorker)
+      self.postMessage(data);
+    else
+      self.postMessage(data, location);
+  }
+  var ws = new WebSocket(url);
+
+  ws.addEventListener('open', function() {

[pkalinnikov, 2017/03/02 12:33:53]

Is there a reason why you use such a syntax instead of overriding 'onopen'
attribute of the WebSocket object?
Example:
https://cs.chromium.org/chromium/src/chrome/test/data/extensions/api_test/web...

yhirano@: Which one is preferable?

[Charlie Harrison, 2017/03/02 14:48:00]

My understanding is the addEventListener pattern is slightly more preferred
because it allows multiple listeners. I've seen them used interchangeably in JS
tests though so I'm not sure there is an enforced policy.

[yhirano, 2017/03/03 06:15:22]

Either is fine, I think.

Personally, I prefer addEventListener for objects we (or libraries) may add
event handlers multiple times, such as Window, Document, Element, etc. I don't
care about WebSocket because in most cases we set event handlers only once at
the creation time.

[pkalinnikov, 2017/03/03 10:19:06]

On the second look, I find plenty of "ws.onopen" usage in the codebase:
https://cs.chromium.org/search/?q=%22ws.onopen+%3D%22&type=cs
But only 2 occurrences of ".addEventListener('open'" here:
https://cs.chromium.org/search/?q=%5C.addEventListener%5C(%27open%27&type=cs

Could we resort to the more popular one? I guess we don't need multiple handlers
in this test.

[Charlie Harrison, 2017/03/03 13:59:26]

Yes. Indeed you are right onopen seems more popular than the event listener, at
least for websockets. Changed it.

I left the self.addEvenetListener because we do need multiple of these,
depending on how this script is executing.

+    ws.send('hello world');
+  });
+
+  ws.addEventListener('close', function() {
+    messageMainContext("onclose");

[pkalinnikov, 2017/03/02 12:33:53]

nit: Please use single quotes here as well.

[Charlie Harrison, 2017/03/02 14:48:00]

Done.

+  });
+
+  ws.addEventListener('message', function() {
+    messageMainContext('onmessage');
+  });
+}
+
+self.addEventListener('message', function(e) {
+  // Will only receive a message with a URL in it if this JS is executing in a
+  // worker.
+  if (e.data.url) {
+    connectWebSocket(e.data.url, true /* inWorker */);
+  }
+});
+