I'm working through the JS SPA book and noticed I get different results in chrome vs firefox. Here is the code...
<!doctype html>
<html>
<head>
<title>SPA Chapter 1 section 1.2.2</title>
<style type="text/css"></style>
<script type="text/javascript">
var prison = function () {
console.log('made it to prison');
};
prison();
</script>
</head>
<body>
<div id="spa"></div>
</body>
</html>
Nice and simple...no? In chrome I get the expected result of "made it to prison" in the console. However, in FF only get an error that reads...
The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol.
What gives? Is there a setting I'm missing in the FF webdev console?
Firefox shows the expected result in the console log, when you enable console logging in dev tools. It also shows a message, classified as an error message in some versions but not affecting the functionality. It is effectively an informational message that says that the character encoding of the page was not declared in any way; see the W3C page on encodings.
The way to control what is shown in the console log depends on the dev tools you are using. Using the built-in dev tools in the current version of Firefox, called Aurora, which you can invoke with Ctrl Shift K, make sure that “Logging” is enabled (appears in black, not grey) as in this image:
You need to decide on the character encoding. For any modern application, there is seldom need to consider any other option than UTF-8. You can declare it by saving the HTML file as “UTF-8 with BOM” in your text editor and/or by using the tag <meta charset=utf-8> in the head part. If you only use the latter and if the page is ever sent via HTTP, you should make sure that the server does not send conflicting information in the Content-Type HTTP header.
Related
The following code shows an <iframe sandbox... pointing to a page that opens a test websocket with a message on successful open. It works correctly on Chrome and Edge printing the It worked! message immediately.
On Firefox it fails with Uncaught DOMException: The operation is insecure. and no further reasoning.
<!DOCTYPE html>
<html lang="en">
<body>
<iframe
sandbox="allow-scripts"
src="https://firefox-wss-example.tiiny.site/"></iframe>
</body>
</html>
The linked websocket page source code is simply as follows:
<!DOCTYPE html>
<html lang="en">
<body>
<script>
const ws = new WebSocket('wss://demo.piesocket.com/v3/channel_1?notify_self');
ws.addEventListener('open', () => {
console.log('It worked!');
});
</script>
</body>
</html>
I have tried a mixture of wss:// and ws://, as well as permissive CORS headers, but none of my attempts fix the issue on Firefox despite having an appropriate setup. I am starting to think this is a Firefox 97 bug but am unsure of how to verify.
Why does this snippet work on most browsers but fails on Firefox?
I've been through this before, spend weeks on investigations, what I found is: Firefox runs sandboxed JavaScript under the blob:// protocol, and you're only allowed to upgrade to WebSocket from http:// and https:// connections. blob:// isn't either.
Although it's not very clear in their documentation, you may take a look into the websocket upgrade implementation as well as in this issue about CSP inheritance to understand it better, but it's basically the way Firefox have chosen to implement Sandboxing.
We never found a workaround for this, the only way was to drop the Sandboxing, or drop Firefox support for this specific feature.
On the other hand, Chromium based browsers saves the script file locally (I cannot say with 100% of confidence if it is stored in a temporary directory or virtual file system), and still uses the http:// protocol to access them, this way you can upgrade to ws:// or wss://. Those browsers may also inherit CSP, since they keeps the opener instance.
Edit: This problem is not tied to an specific Firefox version, it has been implemented this way for a long time. I has been 5 or 6 releases from the time I went into this problem, it still this way, and will probably stay this way, it's not considered a bug and it's not close to a highly requested feature.
my ojet application does not work in mozilla firefox or internet explorer. It says in Mozillas console:
The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature. localhost:8443
Try adding below tag by specifying encoding type in your view page i.e html file. Refer this thread for more information.
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
Using the following code to generate a pop-up with no URL bar
<head>
<title></title>
<script type="text/javascript">
function open_on_entrance() {
window.open('http://address.com', 'popsearch', 'resizable,dependent,status,width=1100,height=700,left=10,top=10')
}
</script>
</head>
<body onload="open_on_entrance()">
Here's the crazy part - the code works when I run it on my model server, but the URL displays when the same code runs on the production server. This is when testing it from the same browser on a separate server.
I know some browsers don't allow the location=no tag, but is there a setting on a server that would disallow it?
Your code works. However check the following things.
You have cleared your browser cache.
Your browser has blocked
pop-ups.
The server does not affect the result of the code.
You didn't say which browser, but there's a funny setting in Internet Explorer which forces the URL bar to always show. Make sure this is set to enabled!
IE 11/
Tools /
Internet options /
Security /
(pick the right zone for your site, usually trusted) /
Custom Level Under "Miscellaneous" /
Under "Allow websites to open windows without address or status bars" /
Set to enabled
I'm getting a "Resource interpreted as Script but transferred with MIME type text/plain" warning in Google Chrome when including a local script file.
I know the problem appears when loading a file from a server or through ajax which most often depends on wrong headers being set.
The weird thing is that I get this warning even though it is run from a local folder: file:///C:/test/foo.html
This happens only in Chrome with the most basic html there is:
<!DOCTYPE html>
<html>
<head>
<script type="text/javascript" src="bar.js"></script>
</head>
<body>
</body>
</html>
bar.js is also as simple as it can get:
function hello() {}
I've tried adding a meta tag:
<meta http-equiv="content-script-type" content="text/javascript">
and tested with other doctypes but nothing seems to help.
This obviously isn't a real issue since the scripts still work fine, but I'm working on a large project and currently have around 150 scripts included. It therefore makes it difficult to see when an actual warning occurs in between them.
Everything works fine when I run the file on a server, locally or remote.
Any ideas on why chrome is annoying me with this?
I figured it out!
The Visual Studio installer must have added an errant line to the registry.
open up regedit and take a look at this registry key:
See that key? The Content Type key? change its value from text/plain to text/javascript.
Finally chrome can breathe easy again.
I should note that neither Content Type nor PercievedType are there by default on Windows 7, so you could probably safely delete them both, but the minimum you need to do is that edit.
Anyway I hope this fixes it for you too!
I tried fixing this problem using this method but it didn't work for me.
My problem was that IIS manager didn't have MIME types in HTTP Features.
I was able to turn it on by enabling Static Context via...
--> Control Panel
--> Programs
--> Turn Windows features on or off
--> Internet Information Services
--> World Wide Web Services
--> Common HTTP features
--> [X] Static Content.
After this, MIME types appeared and everything started working again.
The accepted answer is a great one! However, just to post an answer for those who encounter problem like me, who use a department/college computer sometimes, where I do not have the permission to change any key value in regedit.
Change
<script type="text/javascript" src="main.js"></script>
to
<script src="main.js"></script>
Although the error message still exist, the page loaded correctly.
Because IE doesn't support Asynchronous file uploads, I'm using a work-around that involves posting a form to an iframe. I bind the the onLoad event of the iframe and read its contents when the event is fired. This works well, except when the server returns a status code other than 200, in which case IE8/IE9 throws a "SCRIPT5: Access is denied" error. It seems Microsoft have decided that no one should be allowed to read the contents of an iframe unless the request returns 200 OK.
Googling has turned up nothing, so here I am seeking help. Can anyone else reproduce this odd behavior? Is there anyway around this issue?
The iframe does not violate any cross-site security policies. It's all on the same domain.
I think I've worked this one out while trying to reproduce the problem on fiddler. Turning off the "Show Friendly HTTP error messages" in IE seems to fix it. The reason I couldn't reproduce it on fiddler is that their 404 pages are over 512 bytes, hence it would show the nginx error regardless.
Basically, the whole issue is that when a page is less than 512 bytes (or 256 in some cases), IE seems to substitute the whole page which has the consequence of blocking access to that page programmatically. Obviously an oversight by Microsoft which still seems to be present in IE10.
It's easy to reproduce. Just place the following in a file (e.g. test.html) under a server than returns a 404 response code under 512 bytes, and ensure your IE is set to show friendly error messages (also make sure "test1.file" doesn't actually exist). Hit the page with IE with the developer console open, and you should see a "access denied" error. How you refresh the page alters the outcome. A CTRL+F5 doesn't seem to exhibit the problem, but a CTRL+R or F5 does.
<!DOCTYPE html>
<html lang="en">
<head>
</head>
<body>
<script type="text/javascript">
iframe = document.createElement('iframe')
iframe.src = '/test1.file'
document.body.appendChild(iframe )
iframe.contentDocument
</script>
</body>
</html>
Now, if only I could find where I can submit bug reports for IE10 so we can make our life dealing with this horrific browser just a little better.