From 716aae4236e409f2ab11916c1cbe3fe3ce9a9d0f Mon Sep 17 00:00:00 2001 From: Raymond Hill Date: Sun, 21 Jul 2019 20:53:42 -0400 Subject: [PATCH] Reverting fix to https://github.com/gorhill/uBlock/issues/3639 Related feedback: - https://github.com/uBlockOrigin/uAssets/commit/a54cb2e38f7b2af972f2ddee8fd86350d6f2e07c#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. --- src/js/redirect-engine.js | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/js/redirect-engine.js b/src/js/redirect-engine.js index 9368c8127..01cdf03b1 100644 --- a/src/js/redirect-engine.js +++ b/src/js/redirect-engine.js @@ -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()}`; }