fetch API and filesystem: URLs (a Manifest v3 migration blocker)

Hi third_party/blink/renderer/core/fetch/OWNERS (nidhijaju, ricea),
CC'ing blink-dev and chromium-extensions. Feel free to CC other people
or lists if they're relevant.

How hard is it to add filesystem: URL suport to the fetch API? I have
worked with chromium code for some years now, but haven't really
touched blink code generally (and fetch code specifically). For
example, fetch is "a blink thing" and I don't know how problematic
it'll be that Chromium's storage/browser/file_system code lives
outside of third_party/blink.

If it's hard, are there any workarounds to get my XMLHttpRequest-using
extension on to Manifest v3? AFAICT this is a hard blocker for me to
get off Manifest v2.

---

Background:

I work on ChromiumOS' "file manager" app, which uses an "image_loader"
helper extension. This has been MV2 (Manifest v2) for some years now,
and works great.
https://source.chromium.org/chromium/chromium/src/+/main:ui/file_manager/image_loader/manifest.json;l=8;drc=c2aae80e18cbdadde0a3565fa8d5635f2ad378ae

I'm trying to migrate it to MV3 (Manifest v3). This apprently requires
migrating from XHR (XMLHttpRequest) to fetch.
https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers#replace-xmlhttprequest

https://crrev.com/c/5679823 attempts to do just that (assuming that
fetch should work with either MV2 or MV3). But it doesn't.

ChromiumOS' file manager works with real (kernel-visible) files (e.g.
your local downloads) but also virtual files (e.g. cloud storage like
Google Drive or Microsoft OneDrive, or "connect your phone to your
Chromebook via USB cable and see your files over the MTP, uh,
protocol"). While "filesystem:etc" URLs might have been created 10+
years ago as a web-facing API, the storage::FileSystemURL class
currently powers the ChromiumOS file manager too.
https://source.chromium.org/chromium/chromium/src/+/main:storage/browser/file_system/file_system_url.h;l=83-84;drc=71bd8f1596b301a842247d3488f901d7ae3dfad2

filesystem: URLs work with XHR. They do not work with fetch.

When manually testing the https://crrev.com/c/5679823 change, I get an
error logged:

"Fetch API cannot load filesystem:chrome-extension://etc/etc. URL
scheme "filesystem" is not supported."

This comes from here:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/fetch/fetch_manager.cc;l=926-928;drc=6c848b551a600625f8b361d1eaad4f8e94d1e40a

It's triggered by passing "RendererCorsIssueCode::kCorsDisabledScheme"
here (although I don't think CORS is actually involved; the error code
is a placeholder):
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/fetch/fetch_manager.cc;l=907-910;drc=6c848b551a600625f8b361d1eaad4f8e94d1e40a

In fact, right next to that trigger is "// FIXME: implement other
protocols". The FIXME dates from 2014:
https://codereview.chromium.org/399543002/diff/370001/Source/modules/serviceworkers/FetchManager.cpp

I'm guessing that, if it hasn't been fixed in 10 years, it's probably
not going to get fixed.

If it's not going to get fixed, is there a workaround?

Sending again (this time hopefully to chromium-extensions@).

You can still use XMLHttpRequest inside the offscreen document.

Thanks. I'll take chromium-extensions off the CC list and follow up
with your additional contacts.

Despite sounding similar, the file:// and filesystem:// schemes aren't
completely interchangeable. Furthermore, our manifest.json's
content_security_policy does not list file: (but it does list
filesystem:) and, IIUC, opening up file: would let the extension e.g
read the entire user profile directory.
The ChromeOS Image Loader extension is 'built into ChromeOS' and
doesn't actually show in the chrome://extensions page. It's a private
implementation detail of the OS UI (the file manager). Even if it did
show, FWIW, on my other extensions, I don't see a "Allow access to
file URLs" toggle on the details pages.

Thanks anyway for the suggestions.

Huh, https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers#replace-xmlhttprequest
made it sound like XHR wouldn't work with MV3 at all:
"XMLHttpRequest() can't be called from a service worker, extension or
otherwise". Perhaps that documentation was written before the
chrome.offscreen API became available (in Chrome 109)??

I will give this a try, although IIUC chrome.offscreen isn't available
to MV2 (unlike fetch, which is available for both MV2 and MV3), so it
looks like I'm going to have to cook up one big "migrate to MV3"
commit instead of multiple, smaller commits.

Does RegisterURLSchemeAsSupportingFetchAPI affect just one particular
extension or the entire process? If the process, is it the browser
process, renderer process or both?