Related feedback:
- a54cb2e38f (commitcomment-34387041)

Regression from converting uBO resources into
immutable resources. This affects only Chromium-based
browsers.

This is a quick fix for the dev build, to at least unbreak
the reported case.

I need to research whether the root issue (conflict with HTTPS-E)
is still occurring, and if so the fix is not trivial: I will need
to add code to uBO to fetch and convert binary data into `data:`
URIs.
This commit is contained in:
Raymond Hill 2019-07-21 20:53:42 -04:00
parent df59c74bf2
commit 716aae4236
No known key found for this signature in database
GPG Key ID: 25E1490B761470C2
1 changed files with 3 additions and 3 deletions

View File

@ -183,7 +183,7 @@ const mimeFromName = function(name) {
// Do not redirect to a WAR if the platform suffers from spurious redirect
// conflicts, and the request to redirect is not `https:`.
// This special handling code can removed once the Chromium issue is fixed.
const suffersSpuriousRedirectConflicts = vAPI.webextFlavor.soup.has('chromium');
//const suffersSpuriousRedirectConflicts = vAPI.webextFlavor.soup.has('chromium');
/******************************************************************************/
/******************************************************************************/
@ -206,11 +206,11 @@ RedirectEntry.prototype.toURL = function(fctxt) {
if (
this.warURL !== undefined &&
fctxt instanceof Object &&
fctxt.type !== 'xmlhttprequest' &&
fctxt.type !== 'xmlhttprequest' /*&&
(
suffersSpuriousRedirectConflicts === false ||
fctxt.url.startsWith('https:')
)
)*/
) {
return `${this.warURL}${vAPI.warSecret()}`;
}