1583657 - Worker with type "application/octet-stream" is blocked on color.adobe.com

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P2)

Description

[Ksenia Berezina [:ksenia]]

As reported here:
https://github.com/webcompat/web-bugs/issues/40472

Steps to reproduce:
In latest Nightly https://color.adobe.com/trends/Wilderness?page=2 and observe the page.

Expected:
Thumbnails should expand to a colour scheme

Actual:
There is three dot loading icon instead and images don't respond to mouse clicks

There is the following error in the console:
Loading Worker from “https://color.adobe.com/extract.jsx” was blocked because of a disallowed MIME type (“application/octet-stream”).

 8:27.55 INFO: Last good revision: ceb340bce4b41a30aa4369471e0469a00a6a5ac2
 8:27.55 INFO: First bad revision: 09edf04895b6a18f9f43ac6b55acdb8d2470ea62
 8:27.55 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ceb340bce4b41a30aa4369471e0469a00a6a5ac2&tochange=09edf04895b6a18f9f43ac6b55acdb8d2470ea62

Looks like Chrome is not blocking the worker with “application/octet-stream” type. Is it something we want to consider for compatibility?

Comment 1

[Tom S [:evilpie]]

This change is only in Nightly for finding issues like this. Can we contact Adobe and ask them to fix this?

Comment 2

[Pascal Chevrel:pascalc (PTO until April 26)]

Nightly only and we are moving 71 to beta in a few days, marking as fix-optional.

Comment 3

[smmehadi]

@ksenia since this content type isn't blocked in chrome, any reason for specifically blocking it in firefox?
do you plan to ship with this blocking in place or it was just an intermediate change for testing/checking compatibility?
i got referred to this issue by Sean Voisen, and looking into it from color team.

Comment 4

[Ksenia Berezina [:ksenia]]

Hi smmehadi, thanks for looking into this.

We're following the spec:

If any of the following conditions are met, throw a "NetworkError" DOMException:

• The result of extracting a MIME type from response's header list is not a JavaScript MIME type

As far as I know Chrome is on the same page with us on blocking scripts with wrong MIME types. They did not ship it yet since they would like to do more analysis. There is a discussion here https://github.com/whatwg/html/issues/3255 .

We've decided to delay blocking worker scripts in release and are limiting this change to Beta/Nightly to find issues like this.

It will eventually land in release though, so it would be great if your team could look into changing MIME type of the affected worker script.

Comment 5

[smmehadi]

Ok Ksenia. is the application/javascript the correct type in this case which firefox/chrome will support?

Comment 6

[Tom S [:evilpie]]

Yeah, application/javascript or text/javascript is fine. Any JavaScript MIME type works.

(In reply to Ksenia Berezina [:ksenia] from comment #4)

Hi smmehadi, thanks for looking into this.

We're following the spec:

If any of the following conditions are met, throw a "NetworkError" DOMException:

• The result of extracting a MIME type from response's header list is not a JavaScript MIME type

Enforcing the MIME type of Worker scripts is not part of the spec yet. I would still strongly recommend to fix this. What you are quoting only applies to importScripts inside a Worker.

Comment 7

[smmehadi]

Thanks Tom. Any timelines by when this check will go out with builds, this will help us in prioritization of the issue.

Comment 8

[Tom S [:evilpie]]

Hey! Can you please look into this? I imagine fixing this would just involve renaming the file extract.jsx to extract.js.

Chrome might be willing to try this change as well: https://github.com/whatwg/html/issues/3255#issuecomment-554266705

Comment 9

[smmehadi]

Thanks @Tom. we are working on this fix.

Comment 10

[Tom S [:evilpie]]

Seems like this was finally fixed at some point.