fix: webRequest module should work with file:// protocol #22903
Conversation
40e7a52 to
f3f572d
Compare
shell/browser/protocol_registry.cc
Outdated
| // | ||
| // Note that |insert| or |emplace| should not be used here, as they do nothing | ||
| // if the key already exists, while we would like to overwrite the factory. | ||
| (*factories)[url::kFileScheme] = std::make_unique<AsarURLLoaderFactory>(); |
There was a problem hiding this comment.
When extension system is enabled, it also registers a factory for file:// https://github.com/electron/electron/blob/master/shell/browser/electron_browser_client.cc#L1281 , it seems to override this one for sub resources. Will that be okay ?
There was a problem hiding this comment.
Actually the problem is other way around, the extension system uses emplace to register, so it won't override our factory. But then question, its trying to register a file provider with stricter rules https://github.com/electron/electron/blob/master/shell/browser/electron_browser_client.cc#L1202 and that won't be available, is that okay ? Or can we accommodate that configuration here ?
This problem is unrelated to the changes in this PR, but want to see if we can solve it here.
There was a problem hiding this comment.
The url factory installed by extension system is to support file:// under chrome-extension:// schemes, Chromium only installs file url factory for file:// and about:blank so it is fine for extension system to use emplace.
The problem is we are unconditionally installing asar url factory for all protocols, I have updated the code to only install it when needed.
f3f572d to
656a859
Compare
|
Release Notes Persisted
|
|
I was unable to backport this PR to "7-2-x" cleanly; |
|
I was unable to backport this PR to "9-x-y" cleanly; |
|
I was unable to backport this PR to "8-x-y" cleanly; |
* fix: override file:// instead of intercepting * test: webRequest module should work with file:// * fix: service work with file:// url * fix: original_response_headers can be null * fix: only register file:// when necessary
Description of Change
Fix #22370.
When supporting asar archives in
file://URL, overwrite the defaultFileURLLoaderFactorydirectly instead of intercepting the protocol inProxyingURLLoaderFactory. OtherwisewebRequestwon't be able to proxy thefile://requests.This is actually the correct way to override
file://protocol, previous implementation was essentially a hack.Checklist
npm testpassesRelease Notes
Notes: Fix
webRequestmodule not working withfile://protocol.