WebSockets not supported when loaded from non-default scheme

WebSockets can only be used from so-called standard schemes: http, https, file, ftp, qrc and some others. Attempting to open a WebSocket from a custom scheme results in an immediate CloseEvent with code 1006 Abnormal Closure.

The problem can be worked around by registering the custom scheme as 'standard', however this has the side-effect of changing how Chromium parses and canonicalizes URLs. Using the workarounds below results in Chromium expecting the URLs to have hostnames. For example, both the URLs foo:a/b/c and foo:/a/b/c will be parsed as having the hostname a and path /b/c. The canonicalized form will be foo://a/b/c. Additionally this means that the same-origin policy will be applied to the custom scheme, meaning that a page from foo:a/c might not be allowed to load the resource foo:b/c because they have different "hosts" a & b.

WORKAROUND FOR 5.10 & 5.11

The custom scheme must be registered as standard by patching ContentClientQt::AddAdditionalSchemes:

 
diff --git a/src/core/content_client_qt.cpp b/src/core/content_client_qt.cpp
index 66c63b1b..0c2c54c6 100644 
--- a/src/core/content_client_qt.cpp 
+++ b/src/core/content_client_qt.cpp 
@@ -321,6 +321,7 @@ std::string ContentClientQt::GetProduct() const 
  
 void ContentClientQt::AddAdditionalSchemes(Schemes* schemes) 
 { 
+ schemes->standard_schemes.push_back("xxx"); 
     schemes->secure_schemes.push_back(kQrcSchemeQt); 
 } 

WORKAROUND FOR 5.9

The custom scheme must be registered as standard by patching Chromium's url library in src/3rdparty:

 
diff --git a/chromium/url/url_util.cc b/chromium/url/url_util.cc 
index 0a84d5e23c..38c1b44a00 100644 
--- a/chromium/url/url_util.cc 
+++ b/chromium/url/url_util.cc 
@@ -19,8 +19,9 @@ namespace url { 
  
 namespace { 
  
-const int kNumStandardURLSchemes = 10; 
+const int kNumStandardURLSchemes = 11; 
 const SchemeWithType kStandardURLSchemes[kNumStandardURLSchemes] = { 
+ {"xxx", SCHEME_WITHOUT_PORT}, 
     {kHttpScheme, SCHEME_WITH_PORT}, 
     {kHttpsScheme, SCHEME_WITH_PORT}, 
     // Yes, file URLs can have a hostname, so file URLs should be handled as 

The previous description of this ticket was referring to a different problem to do with forwards compatibility of profile data (sqlite error).