[v4.0.0-next.3] Incorrect implementation of `loadWasmFactory`

[fs-eire]

The string replacement in function loadWasmFactory is incorrect implemented.

original code: https://cdn.jsdelivr.net/npm/onnxruntime-web@1.25.0-dev.20260212-1a71a5f46e/dist/ort-wasm-simd-threaded.asyncify.mjs

var a=new Worker(new URL(import.meta.url),{type:"module",workerData:"em-pthread",name:"em-pthread"});

The actual code being executed in the browser:

var a = new Worker(new URL("https://cdn.jsdelivr.net/npm/onnxruntime-web@1.25.0-dev.20260212-1a71a5f46e/dist"),{
            type: "module",
            workerData: "em-pthread",
            name: "em-pthread"
        });

[fs-eire]

using a blob URL need to be very careful. There are multiple restrictions:

• CORS headers
• blob URL not working for service worker manifest v3

There are 2 places that may import the .mjs file:

1. the main thread or worker thread that imports ORT web, can be static (bundled by bundler at compile time) or dynamic (using import() at runtime).
2. ORT internally spawn workers when numThreads > 1. Uses new Worker(...
   • when (1) is a dynamic import, this step usually use the same URL
   • when (1) is static import, this step uses a hacked way to make webpack happy
     eg. https://cdn.jsdelivr.net/npm/onnxruntime-web@1.25.0-dev.20260218-19c9efc4ac/dist/ort.jspi.bundle.min.mjs

     new Worker((()=>{let r=URL;return import.meta.url>"file:"&&import.meta.url<"file;"?new r("ort.jspi.bundle.min.mjs",import.meta.url):new URL(import.meta.url)})(),{type:"module",workerData:"em-pthread",name:"em-pthread"})

If transformers.js want to always use dynamic import in (1), make sure not using the blob URL approach for the restricted scenarios.

[nico-martin]

Hi @fs-eire

Thank you for looking into the problem and opening the issue.
I took another look at the whole thing, and the problem is that we also want to cache the .mjs file to provide full offline capabilities.
However, the problem is that ONNX Runtime reads the file as a dynamic import, which in turn means that it bypasses the Cache API (what we use to cache files). So we have to fetch it ourselves and then pass the content to the runtime. Using a blob is as far as I know the only way to do that.

[nico-martin]

so after another investigation I think we need to stick to blobUrl for offline usage. But I am more than open if you have a better idea.
My current idea is to add a canUseBlobURL check and to also allow users to opt-out if they want to.
@fs-eire, do you think that solves the problem?

[xenova]

To add on to what @nico-martin said, we're really hoping it is possible to cache the .mjs file... to provide full offline support.

[fs-eire]

I think it is still technically possible to achieve that if it's done correctly.

What is the problem if you don't rewrite the content of .mjs file?

===================

EDIT:

Let me rephrase my question.

I understand the requirement that you want to cache the .wasm AND the .mjs file. However, I don't fully understand what is the current problem. I read the following explanation:

I took another look at the whole thing, and the problem is that we also want to cache the .mjs file to provide full offline capabilities.
However, the problem is that ONNX Runtime reads the file as a dynamic import, which in turn means that it bypasses the Cache API (what we use to cache files). So we have to fetch it ourselves and then pass the content to the runtime. Using a blob is as far as I know the only way to do that.

what is exactly the problem with dynamic import and/or with Worker creation?

[fs-eire]

I did some testing locally. I think this PR should help a little bit if you are interested:

• [web] fix usage of wasmBinary together with a blob URL for .mjs microsoft/onnxruntime#27411

[nico-martin]

what is exactly the problem with dynamic import and/or with Worker creation?

The problem is that without the replace I get Failed to construct 'URL': Invalid URL. The reason for this is:

1. Inside the blob, import.meta.url is still blob:... .
2. ORT then tries new URL("ort-wasm-simd-threaded.asyncify.wasm", "blob:...").
3. JavaScript throws because blob URLs can't be base URLs.

Therefore I had to replace the blob.. with a URL.

If I understand correctly, it would not be necessary to replace import.meta.url with your PR, correct?
But we still have to to the blobUrl Caching and also the canUseBlobURLs check.

[fs-eire]

If I understand correctly, it would not be necessary to replace import.meta.url with your PR, correct?

I think so.

But we still have to to the blobUrl Caching and also the canUseBlobURLs check.

I think you may still need this canUseBlobURLs() function, but the implementation may be less strict. In my understanding service worker is the only use scenario that you cannot use a blob URL

[nico-martin]

@fs-eire, It would be great if you could implement it that way!

service worker is a perfectly reasonable limitation. To be honest, I can't think of any case where it would make sense to run transformers.js in a service worker. And if there were, it would be easy for them to implement caching via service worker. Service worker caching happens at the network level, which is why it also takes into account requests that are loaded via import.

[fs-eire]

if apply this PR, does it work with removing the check for crossOriginIsolated and numThreads in canUseBlobURLs()?

[nico-martin]

Unfortunately I can't verify it because of another issue.

Also I have one question about the fix. config.locateFile = (fileName) => fileName; should fix the new URL().href error. But this is only applied if there is a flags.wasmBinary. Theoretically, however, they have nothing to do each other. I could pass a wasmBinary without passing a blob via wasmPaths.mjs, just as I could pass a blob via wasmPaths.mjs without a wasmBinary. In that case, I would probably run into a problem again, right?