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

18 views
Skip to first unread message

Nigel Tao

unread,
3:15 AM (10 hours ago) 3:15 AM
to Nidhi Jaju, Adam Rice, blink-dev, Chromium Extensions
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?

Nigel Tao

unread,
9:05 AM (4 hours ago) 9:05 AM
to Nidhi Jaju, Adam Rice, blink-dev, Chromium Extensions
Sending again (this time hopefully to chromium-extensions@).

woxxom

unread,
1:18 PM (8 minutes ago) 1:18 PM
to Chromium Extensions, Nigel Tao, Nidhi Jaju, Adam Rice, blink-dev
You can still use XMLHttpRequest inside the offscreen document.
Reply all
Reply to author
Forward
0 new messages