Consider this simple HTML file:
<!DOCTYPE html>
<html>
<body>
<script type="text/javascript">
alert('1');
</script>
</body>
</html>
When I enable Firefox JavaScript Debugger (via Ctrl+Shift+S), the panel shows me the following error message instead of the source code:
Error loading from source:
loadSourceError
What am I doing wrong?
My bet is that it comes from some server setting, since it works fine from another server (as well as locally), but I cannot identify any noticeable difference between both configurations (apache.conf are identical, /etc/apache2/sites-enabled/ configuration is similar, enabled modules are the same. I had the hope that installing the javascript-common debian package would help, but it does not…).
JavaScript itself is served correctly, though (even the embedded JS), and there is no loading problem for JS files.
Got it!
It seems that the debugger has issues with internationalized domain names (IDN).
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.
I'm having difficulties implementing something simple: I have an index.html file served on http://localhost:3200 by ruby on rails, which uses a javascript file served on http://localhost:8000 by webpack-dev-server.
So here's what I have:
<!doctype html>
<head>
<script crossorigin="anonymous" src="http://localhost:8000/app.js" />
</head>
<!-- ... -->
</html>
My app.js file is sent with, amongst others, the following header:
Access-Control-Allow-Origin: *
What I want is to be able to override window.onerror in app.js, and see caught errors, rather than "Script error".
What am I missing?
-- edit --
Since it might not be clear enough: my script does load. I have no problem with that. My issue is that I need to report errors that happen to somewhere else, but I can't do that since any error that occurs in app.js is reported as "Script error" rather than something more explicit.
What sourcemap (devtool) are you using?
I was getting this issue, and it changing from eval-source-map to source-map fixed it.
This is a google chrome issue, should be when Chrome 71 is released.
Here are the relevant issue threads:
https://bugs.chromium.org/p/chromium/issues/detail?id=765909
https://github.com/webpack/webpack/issues/5681
Edit: This also impacts electron users.
I am trying to load a txt file using jquery in Chrome. Why it does not work? I have copied this code snippet from w3schools, and all i have changed is their url.
<!DOCTYPE html>
<html>
<head>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js">
</script>
<script>
$(document).ready(function(){
$("button").click(function(){
$("#div1").load("http://stackoverflow.com/questions/15114993/how-to-embed-a-file-in-html-using-jquery-load");
alert("clicked");
});
});
</script>
</head>
<body>
<div id="div1"><h2>Let jQuery AJAX Change This Text</h2></div>
<button>Get External Content</button>
</body>
</html>
Chrome throws the following error when executing your code:
Origin null is not allowed by Access-Control-Allow-Origin.
You must:
Host your HTML code on your local web server, so that it is accessible at:
http://localhost/your_directory/index.html
Update your code to load your out.txt, placed in the same folder where your index.html file is, like this (using relative paths)...
$("#div1").load("out.txt");
...or like this (using absolute paths):
$("#div1").load("http://localhost/your_directory/out.txt");
And you are done! :-)
Ok the issue you are probably having here seems to happen allot with chrome and ajax requests. Chrome throws a security issue if running locally try putting your code on a web server, or try firefox.
Or if your on a mac you can open chrome using like this from the command line to prevent the security issue
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-files
There are loads of posts on google if your search for "allow file access from files chrome"
Good luck
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.
i am using requires.js 2.0. I have the following simplified use case:
my HTML file:
<!DOCTYPE HTML>
<html>
<head>
<title></title>
<script type="text/javascript" data-main="apptest.js" src="../_js/libs/require/require.js"></script>
</head>
<body>
</body>
</html>
And then in apptest.js:
requirejs.config({
paths: {
'text': '../_js/libs/require/text'
}
});
requirejs(
['text!boxes.html'],
function (Boxes) {
alert("done");
}
);
Ok, so it doesn't really do much, but enough to make my point. Only in Firefox (14.0.1) i get an exception "uncaught exception: java.security.AccessControlException: access denied (java.io.FilePermission .\boxes.html read)".
So, require.js successfully loaded the text plugin, but fails loading my html file, which i want to use as a template later on. In Google Chrome and even IE9 it works just fine. I am on Windows 7.
I am running this on a local webserver, so no file://... requests here.
I have checked, if i have any special permissions set on the html file, but have not found anything suspicious.
Anyone have an idea?
Update: Running the test in Firefox 13.0.1 does actually work for me without errors. So could it be, that this is a bug, that has been introduced in firefox 14?
I was having the same problem a minute ago. I've fixed it by doing the following in the main.js file (where you setup the config)
Before the
require.config({.....
add the following code:
Packages = undefined;
This should do the trick.
You should have something like this:
Packages = undefined;
require.config({
baseUrl: theAppBaseUrl,
paths: {
Basically the explanation is that it is trying to use Java to get the file instead of an ajax request (for whatever reason). This forces it to use an XHR object to fetch it.
Cheers!