m.king@ can you please provide the test extension for further triage of the bug.

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

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?

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

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.

Deleted: FirebaseAuthSample.zip 108 KB

FirebaseAuthSample.zip 108 KB Download

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

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?

Whoops!  [1] https://chromium.googlesource.com/chromium/src/+/a96166c52ce9b57d7fe616fef2609e7546ef1ba4/net/base/mime_util.cc#225

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.

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?)

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.

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

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...!!

Deleted: 762483.mp4 1.0 MB

	762483.mp4 1.0 MB View Download

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

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

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.

Deleted: 762483.PNG 205 KB

	762483.PNG 205 KB View Download

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.

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

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

Yes you can.

Thanks

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

Updating the status to 'WontFix' based on the comment #21.

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.

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

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