Worker with type "application/octet-stream" is blocked on color.adobe.com
Categories
(Web Compatibility :: Desktop, defect, P2)
Tracking
(Webcompat Priority:?)
Webcompat Priority | ? |
People
(Reporter: ksenia, Unassigned)
References
(Regression, )
Details
(Keywords: regression, Whiteboard: [sci-exclude])
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?
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
This change is only in Nightly for finding issues like this. Can we contact Adobe and ask them to fix this?
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 2•4 years ago
|
||
Nightly only and we are moving 71 to beta in a few days, marking as fix-optional.
@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.
Reporter | ||
Comment 4•4 years ago
•
|
||
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.
Ok Ksenia. is the application/javascript the correct type in this case which firefox/chrome will support?
Comment 6•4 years ago
|
||
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.
Thanks Tom. Any timelines by when this check will go out with builds, this will help us in prioritization of the issue.
Comment 8•4 years ago
|
||
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
Thanks @Tom. we are working on this fix.
Comment 10•3 years ago
|
||
Seems like this was finally fixed at some point.
Updated•3 years ago
|
Updated•1 year ago
|
Description
•