This might not appear with HTML + JavaScript files that are opened in the browser from the local file system (per the URL). However, if the HTML is opened from a remote origin (including localhost), the browser will send a HTTP GET
request to retrieve this referenced resource. The response will include a number of HTTP headers as supplied by the server, which usually includes the Content-Type
header too. This header declares the MIME type for the resource retrieved. And hence, if that's not one of the JavaScript MIME types, the browser produces the warning.
Now, the MIME type from the Content-Type
HTTP header might be a different one, but the browser likely might try nonetheless to read the response's body as JavaScript code. And this is where the error can occur, if in fact the response body can't be parsed as JavaScript code.
A typical reason for this can be that you don't get JavaScript code served from the server, but a HTML error page, which the server might be configured to send in case of HTTP response status codes 404, 403, 500 or other ones like that.
If the server can't find or resolve the requested resource on its internal lookup mechanism, or if the server is lacking permission to access the resource, it will not be able to send it back to the browser as the response.
In the 403 case (also used for the case where the server denies the client the response for lack of successful prior authentication), it could well be that the rights are 600 (rwx only for the owner) or similar, so if your user account is the owner, you can successfully open the HTML + JavaScript from the local file system (per the URL), but as the server daemon might not run under your user account (but a separate account, and/or be part of a group), with lack of the read-permission for the file for group or anybody, the server is not allowed to access the file (if that's the source for the requested resource), therefore can't reply it to the requester/client/browser, and resorts to a HTTP error code, for which a HTML error page might be configured.
To investigate the actual cause of, and solution to, the problem, you may try to open the full (absolute) URL as the browser constructs it (which is relative to the remote host origin) and see what you get as response. With a Web Inspector/Debugger console, if there's a network monitor, you can investigate the headers of the response and the body payload. These may include indications of what exactly went wrong, if not in a production environment configuration. If you have access to (are in control of) the server, you can also take a look into the server's access/error logs, if any. And investigate the server's retrieval/routing/resolving to its internal source.