1824839 - FF nightly regression: WorkerGlobalScope.importScripts failing with blob URL

Status: RESOLVED WONTFIX

(Core :: DOM: Workers, defect)

Description

[Sam Clegg]

Attachment: Copy of failing test

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36

Steps to reproduce:

The emscripten CI tests on github started reporting a new test failure yesterday: test_preload_file_with_manual_data_download_pthreads .

We test against FF nightly and this test was passing until yesterday.

Actual results:

NetworkError: WorkerGlobalScope.importScripts: Failed to load worker script at blob:http://localhost:8888/fc65d367-3917-4d2d-bfe4-a911346944e9 (nsresult = 0x80530013) / undefined

Expected results:

Test should have passed without an exception being thrown.

Comment 1

[Sam Clegg]

Downstream emscripten bug: https://github.com/emscripten-core/emscripten/issues/19080

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

:aiunusov, since you are the author of the regressor, bug 1819626, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1819626

Comment 4

[Artur Iunusov]

This change was made very recently and only for Nightly (Not for beta and release).
Sorry for the inconvenience. This change was based on the last spec change, which enables strict JavaScript mime type enforcement for worker imported scripts:
https://github.com/whatwg/html/issues/8869,
https://github.com/whatwg/html/pull/4001
https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts

Possible solutions:

1. fix emscripten test, in manual_download_data.html:192
   explicitly specify MIME type for the blob data
   Module['mainScriptUrlOrBlob'] = new Blob([data] , { type: 'application/javascript' });

2. if that previous solution is not suitable for you, then spec change is required in order to allow empty MIME type.
   It seems that Safari does not allow to load blobs without specified MIME type as well: importScripts(URL.createObjectURL(new Blob(["test"]))); should result in a network error (but worth to try on your side)

Comment 5

[Artur Iunusov]

(In reply to Artur Iunusov from comment #4)

This change was made very recently and only for Nightly (Not for beta and release).
Sorry for the inconvenience. This change was based on the last spec change, which enables strict JavaScript mime type enforcement for worker imported scripts:
https://github.com/whatwg/html/issues/8869,
https://github.com/whatwg/html/pull/4001
https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts

Possible solutions:

1. fix emscripten test, in manual_download_data.html:192
   explicitly specify MIME type for the blob data
   Module['mainScriptUrlOrBlob'] = new Blob([data] , { type: 'application/javascript' });

2. if that previous solution is not suitable for you, then spec change is required in order to allow empty MIME type.
   It seems that Safari does not allow to load blobs without specified MIME type as well: importScripts(URL.createObjectURL(new Blob(["test"]))); should result in a network error (but worth to try on your side)

@sbc, could you, please, review the proposed solutions. And share your feedback?

Comment 6

[Sam Clegg]

Thanks, that good to know. We can make that change to the emscripten test.

I suppose the fact that is already doesn't work in Safari means its unlikely folks are relying on this is production.

Comment 7

[Sam Clegg]

Uploaded an emscripten PR: https://github.com/emscripten-core/emscripten/pull/19088

Comment 8

[Artur Iunusov]

Since the test was fixed, I guess we can close this bug