New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Blocked on:
issue 797712



Sign in to add a comment
link

Issue 762483: Cannot register a service worker with a Chrome Extension on Windows 10

Reported by m.k...@texthelp.com, Sep 6 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36

Steps to reproduce the problem:
1. Include a service worker js file within a chrome extension
2. Register the service worker from within a page
3. The service worker file is loaded as type text/plain. In OSX and Chrome OS the service worker loads as expected. Under Windows 10 the following errors occur

The script has an unsupported MIME type ('text/plain').
firebase-messaging-sw.js Failed to load resource: net::ERR_INSECURE_RESPONSE
Uncaught (in promise) DOMException: Failed to register a ServiceWorker: The script has an unsupported MIME type ('text/plain').

What is the expected behavior?
Chrome should know that the service worker js file is of type application/javascript and act accordingly.

What went wrong?
Service worker files are loaded as type text/plain. OSes don't treat this consistently. Windows is stricter in dealing with the wrong MIME type.

Did this work before? No 

Chrome version: 61.0.3163.79  Channel: stable
OS Version: 10.0
Flash Version: N/A

Here is a link to a modified version of the firebase auth sample to highlight the issue.

https://drive.google.com/open?id=0B-RUuj0hfCVRaEhvQ01uUk8xTEk

To replicate:
1. sideload the extension
2. Click on the icon
3. Click sign-in the Google
4. Inspect the page that appears. In OSX and Chrome OS there will be know error and the service worker will be registered. In Windows the errors will have occurred and service worker will not be registered.
 
worker-osx.png
39.4 KB View Download
worker-win10.png
21.0 KB View Download
console-win10.png
21.5 KB View Download

Comment 1 by pbomm...@chromium.org, Sep 6 2017

Cc: kinuko@chromium.org falken@chromium.org pbomm...@chromium.org
Components: -Blink Blink>ServiceWorker
Labels: M-61
m.king@ can you please provide the test extension for further triage of the bug.

cc'ing kinuko@ and falken@ based on blink>serviceworker.

Comment 2 by pbomm...@chromium.org, Sep 6 2017

Labels: Needs-Feedback

Comment 3 by falken@chromium.org, Sep 7 2017

Cc: lazyboy@chromium.org devlin@chromium.org
Components: Platform>Extensions>API
devlin, lazyboy: any quick ideas why the MIME type of a JS file served from an extension is different on Win 10 compared to other platforms?

Comment 4 by falken@chromium.org, Sep 7 2017

m.king@texthelp.com:  can you provide the extension/repro so we can investigate? The Drive link above doesn't work (not public?)

Comment 5 by m.k...@texthelp.com, Sep 7 2017

I've attached the sample.

Regarding the MIME type, all platforms report the MIME type as text/plain in the dev console it's just that it's only Windows that throws an error.
FirebaseAuthSample.zip
108 KB Download

Comment 6 by sheriffbot@chromium.org, Sep 7 2017

Project Member
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "pbommana@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 7 by rdevlin....@chromium.org, Sep 7 2017

Cc: davidben@chromium.org mmenke@chromium.org
Interesting!  We fetch extension resources through extension_protocols.cc, which basically just creates a URLRequestFileJob for the the resource.  We don't do anything special with the mime type there, so we just rely on the type determined by the net code.  Diving into this a bit, this boils down to MimeUtil::GetMimeTypeFromExtensionHelper() [1].  This just looks at the file extension and tries to find the type.

We have three different places that we check for the extension; in order of priority they are kPrimaryMapping (in mime_util.cc), platform-specific magic (platform_mime_util_*), and kSecondaryMapping (in mime_util.cc).  kSecondaryMapping correctly determines that the type is "application/javascript", but on mac at least, we actually get the result from the platform-specific logic (and on mac, this deduces to text/javascript, instead of application/javascript).

I wonder if the platform-specific logic for win10 incorrectly determines the mime type?  Or if we move the application/javascript mapping to kPrimaryMapping, if that would solve the problem?  (I don't have a win10 machine handy, so can't test.)

+mmenke and davidben@ (/net experts) - any ideas?

Comment 9 by mmenke@chromium.org, Sep 7 2017

Cc: asanka@chromium.org
Can anyone else repro this?  This may be an issue with the local configuration.  This logic looks to have been basically the same since the dawn of Chrome.  You can find the relevant registry entry in HKEY_CLASSES_ROOT/.js/ -> "Content Type" (Which for me is "application/javascript").

[+asanka]:  Who knows MIME types better than I do.

Comment 10 by davidben@chromium.org, Sep 7 2017

Do we even want the extensions code to be sensitive to platform hooks at all? That seems kind of poor regardless of whether it's primary or secondary. Suppose the platform decided .txt was application/javascript. The Service Worker check would get confused.

(Also, that list is puzzling. There's an entry for png in both primary and secondary. Is the latter entry even reachable?)

Comment 11 by mmenke@chromium.org, Sep 7 2017

Note that the mappings are two ways - given an extension, find the mime type (For file URLs).  Given a mime type, pick an extensions (for downloads).  The second png entry is for a different mime type.

Comment 12 by ranjitkan@chromium.org, Sep 11 2017

Labels: Needs-Triage-M61

Comment 13 by falken@chromium.org, Sep 11 2017

Could TE team try to repro this and determine if it's a regression in 61?

Comment 14 by krajshree@chromium.org, Sep 11 2017

Cc: krajshree@chromium.org
Labels: Needs-Feedback
Unable to reproduce the issue on Win-10 and mac 10.12.6 using chrome reported version #61.0.3163.79 and latest canary #63.0.3212.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Sideloaded the extension from comment #5.
2. Clicked on the icon.
3. Clicked sign-in the Google button.
4. Inspected the page that appeared. 
5. Observed that there were no errors in console and the service worker was registered.

m.king@ - Could you please verify the screen cast and please let us know if anything missed from our side.

Thanks...!!
762483.mp4
1.0 MB View Download

Comment 15 by m.k...@texthelp.com, Sep 11 2017

Those steps are correct. I've just repeated those steps again on my machine and on a colleague's machine and we both get the error. Here's a screencast of my machine going through the same steps.

https://drive.google.com/file/d/0B-RUuj0hfCVRN3BUMkVwY1h2WTA/view?usp=sharing

Comment 16 by sheriffbot@chromium.org, Sep 11 2017

Project Member
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 17 by pnangunoori@chromium.org, Sep 13 2017

Cc: pnangunoori@chromium.org
Labels: Needs-Feedback
Unable to reproduce the issue on Windows 10 and Mac 10.12.6 using latest Chrome stable version #61.0.3163.79 and latest Canary #63.0.3213.3. Attached screenshot for reference.

@m.king -- Could you please try by removing all the other extensions and creating a new profile to verify if the issue still persists. 

Thanks in advance.
762483.PNG
205 KB View Download

Comment 18 by m.k...@texthelp.com, Sep 13 2017

Finally got to the bottom of the issue.

Turns out some app installation in the past had changed the .js content type in the registry to text/plain. I'm assuming it was a text editor I had installed. Searching the registry for text/plain found the offending entry. I changed it to application/javascript and the service worker now injects correctly.

Thanks for all your help.

Comment 19 by sheriffbot@chromium.org, Sep 13 2017

Project Member
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 20 by pnangunoori@chromium.org, Sep 13 2017

Labels: Needs-Feedback
@m.king -- Thanks for the reply. As per your comment #18, can we mark this issue as 'Won't Fix'.

Comment 21 by m.k...@texthelp.com, Sep 13 2017

Yes you can.

Thanks

Comment 22 by sheriffbot@chromium.org, Sep 13 2017

Project Member
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 23 by pnangunoori@chromium.org, Sep 13 2017

Status: WontFix (was: Unconfirmed)
Updating the status to 'WontFix' based on the comment #21.

Comment 24 by rdevlin....@chromium.org, Sep 13 2017

It's good to see that this was a local issue and not something with Chrome, but I still find it a bit odd.  Do we want local applications to be able to change the mime type for js files?

I'll leave it up to net OWNERs, since that's where the code is, but I'm not sure what the desired case for that would be.

Comment 25 by liuhao...@gmail.com, Nov 23 2017

I think this issue should be resolved, otherwise browser users will confused about this error, and they don't how to resolve it.

Comment 26 by hirosh...@chromium.org, Dec 27 2017

Blockedon: 797712

Comment 27 by hirosh...@chromium.org, Dec 27 2017

Filed a new  Issue 797712  for tracking the particular issue caused by the local registry key.

Sign in to add a comment