Interesting. Since Worker WebSocket connections are proxied via the main thread, it should make absolutely no difference whether it is in a Worker or not.

Thank you for the high-quality bug report. I will try to reproduce and get back to you.

@ ricea : Friendly ping! Could you please provide any update on this issue.

Thank You!

Reproduced. Definitely works in M60 and not in M62.

I will do a bisect to try to find out where exactly the behaviour changed.

You are probably looking for a change made after 483909 (known good), but no later than 483910 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/d5588cf4ffb5a932dcbfd87cd7761d390c790ea9..51a64d9d83edf4aa46f774f6bcd23f0271aa5366

Suspect:


commit 51a64d9d83edf4aa46f774f6bcd23f0271aa5366
Author: Reilly Grant <reillyg@chromium.org>
Date:   Sat Jul 1 14:39:44 2017 +0000

    Use per-frame or per-worker interface provider in WebSockets
    
    This changes updates the WebSocket implementation so that when a
    WebSocket is opened from a worker the per-worker interface provider
    provided by WorkerThread is used. WebSocketHandle has been refactored so
    that the pipe can be opened from the correct thread.
    
    Bug:  734210 
    Change-Id: Ieb9af218fe9b23011526f3da585cf6f6cf4660d1
    Reviewed-on: https://chromium-review.googlesource.com/556464
    Reviewed-by: Takeshi Yoshino <tyoshino@chromium.org>
    Reviewed-by: Kentaro Hara <haraken@chromium.org>
    Commit-Queue: Reilly Grant <reillyg@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#483910}


This change does indeed make WebSockets opened in a Worker behave differently from those on the main page. I think the specific problem is that WebSockets created in a Worker no longer have an associated |frame_id|. As a result,  SSLManager::OnSSLCertificateSubresourceError() doesn't get passed a |frame_id| when it is called in WebSocketImpl::WebSocketEventHandler::OnSSLCertificateError(). As a result HandleSSLErrorOnUI() in //content/browser/ssl/ssl_manager.cc doesn't find a |web_contents| and so cancels the request without ever looking up the cached user decision.

Assigning to reillyg@ to figure out what to do about it.

It is possible for technically proficient users to workaround the bug by adding the certificate to their certificate store so they they don't need to click through the warning.

I expect almost all affected users will be technically proficient. As such it is not critical to fix for M61. The risk of doing a revert this close to stable is too large compared to the expected benefit.

I think we should target M62 for a fix. If the fix turns out to be complex we can revert on the M62 branch and target M63 for the "real" fix.

I have a patch out that should resolve this issue by partially restoring the old behavior when making a WebSocket connection from a dedicated worker: https://chromium-review.googlesource.com/c/chromium/src/+/651634

 Issue 762999  has been merged into this issue.

This is broken in latest Chrome dev(62.0.3202.9) and Canary(63.0.3208.0) as well, Any CL merged to M61 should be merged to M62 and M63.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/abbd66167ccd383033e46f917bb8984f31253d52

commit abbd66167ccd383033e46f917bb8984f31253d52
Author: Reilly Grant <reillyg@chromium.org>
Date: Fri Sep 08 15:46:11 2017

Open WebSocket through loading context in dedicated worker

Dedicated workers always share a process with the document that created
them and this, rather than a shadow-page, is the loading context that
they use. By opening WebSockets through this loading context user
actions related to the frame in which this document is loaded, such as
clicking through an SSL certificate warning interstitial, apply to
connections from the worker as well.

Bug:  760708 
Change-Id: Ibde562f36c667e419b5636ea572cf0b646262173
Reviewed-on: https://chromium-review.googlesource.com/651634
Reviewed-by: Takeshi Yoshino <tyoshino@chromium.org>
Reviewed-by: Adam Rice <ricea@chromium.org>
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#500599}
[modify] https://crrev.com/abbd66167ccd383033e46f917bb8984f31253d52/net/data/websocket/connect_check.html
[add] https://crrev.com/abbd66167ccd383033e46f917bb8984f31253d52/net/data/websocket/connect_check_worker.js
[modify] https://crrev.com/abbd66167ccd383033e46f917bb8984f31253d52/third_party/WebKit/Source/modules/websockets/WorkerWebSocketChannel.cpp

Your change meets the bar and is auto-approved for M62. Please go ahead and merge the CL to branch 3202 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4bdaedb42bfa016a6b0f6c10581af163525c4434

commit 4bdaedb42bfa016a6b0f6c10581af163525c4434
Author: Reilly Grant <reillyg@chromium.org>
Date: Mon Sep 11 01:05:24 2017

Open WebSocket through loading context in dedicated worker

Dedicated workers always share a process with the document that created
them and this, rather than a shadow-page, is the loading context that
they use. By opening WebSockets through this loading context user
actions related to the frame in which this document is loaded, such as
clicking through an SSL certificate warning interstitial, apply to
connections from the worker as well.

Bug:  760708 
Change-Id: Ibde562f36c667e419b5636ea572cf0b646262173
Reviewed-on: https://chromium-review.googlesource.com/651634
Reviewed-by: Takeshi Yoshino <tyoshino@chromium.org>
Reviewed-by: Adam Rice <ricea@chromium.org>
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#500599}(cherry picked from commit abbd66167ccd383033e46f917bb8984f31253d52)
Reviewed-on: https://chromium-review.googlesource.com/659417
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#114}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/4bdaedb42bfa016a6b0f6c10581af163525c4434/net/data/websocket/connect_check.html
[add] https://crrev.com/4bdaedb42bfa016a6b0f6c10581af163525c4434/net/data/websocket/connect_check_worker.js
[modify] https://crrev.com/4bdaedb42bfa016a6b0f6c10581af163525c4434/third_party/WebKit/Source/modules/websockets/WorkerWebSocketChannel.cpp

Tested the issue on Win-10 using chrome dev version #62.0.3202.18, chrome reported version #61.0.3163.71 and latest canary #63.0.3212.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Downloaded WorkerExample.zip file from comment #0.
2. Navigated to URL: https://startme.biz/view/rdp.html from the merged  issue 762999  as navigating to URL: https://10.1.50.130:9119 led to connection timed out.
3. Opened index.html file from WorkerExample folder in another tab and opened the console.
4. Navigated to unsafe site by clicking on advanced.
5. Opened console in the https://startme.biz/view/rdp.html page and did not observe any error as failed: websocket opening handshake was cancelled on reported version #61.0.3163.71 and observed same error as in latest canary #63.0.3212.0 and chrome dev version #62.0.3202.18.

Note: Observed same behavior in chrome version #60.0.3112.113.

reillyg@ - Could you please verify the screen cast and please let us know if anything missed from our side.

Thanks...!!

Deleted: 760708.mp4 1.4 MB

	760708.mp4 1.4 MB View Download

The original report did not contain enough information to reproduce this issue on startme.biz and the attached WorkerExample.zip requires additional setup in order to reproduce the problem. The commit above contains a new test that verifies the problem has been fixed.

OP, can you verify that this issue has been resolved for your internal site?

Here are the steps to reproduce this issue:

1. goe to https://startme.biz/view/rdp.html

2. accept the cert warning and continue

3. Enter any ip address in the computer field, for example 127.0.0.1

4. Select "Open in existing windows" and Open Dev tools.

5. Click "Connect" and you'll see the following error in console:

.. WebSocket opening handshake was canceled


To see the expected result, before step 5, run the following command in Console:
hi5.appcfg.useWorker = false

You'll see a "Can not connect to the remote computer.." message on the bottom right corner.

I was able to have a successful connection using the same machines and certificate setup as my original post. I wasn't able to get a hold of #62 from your beta download (it's still 61 for me), but I was able to test with #63 canary. I'm on a Windows 7 x64 machine. If #62 becomes available I can test on that as well.

Deleted: recording_dev_63.mp4 737 KB

	recording_dev_63.mp4 737 KB View Download

Marking as verified based on #18.

I can confirm too the fix is working with Version 63.0.3213.0 (Official Build) canary (64-bit).

 Issue 765275  has been merged into this issue.

Works in 62.0.3202.18 (Official Build) beta (64-bit) (cohort: Beta)