Page here
Seems like chrome is the only browser having problems with this bit of javascript. I have found that if I remove the '//' from the CDATA tags chrome will give me a line number for the error - line 48. I dont even know where start with this bug unfortunately. The code works as expected but it just takes a bit longer to load/parse with chrome.
I have tried to use script as an external file (float.js) but the error is the same. In production the code will need to be included in the html body though. Any suggestions?
Edit: It was an extension causing this error, is there any way to code against this?
it was the 'Smooth Gestures' extension. removing fixed
Related
I'm using Google Analyticator and my website is http://gestionalemagazzinoonline.it/
You can see the error in the javascript console.
I think that is the suspected file:
https://github.com/wp-plugins/google-analyticator/blob/master/google-analyticator.php
The problem is also if i disable the plugin, or if i change the source code i don't see the changes (maybe there's a cache?).
How can I fix?
Script tags are meant to write javascript in them, and not html.
You have a script block inside a script block. Remove that, and it will work all fine.
Just doing some JavaScript stuff in google chrome (don't want to try in other browsers for now, in case this is really doing real damage) and I'm not sure why this seemed to break my console.
>var x = "http://www.foo.bar/q?name=%%this%%";
<undefined
>x
After x (and enter) the console stops working... I restarted chrome and now when I do a simple
console.clear();
It's giving me
Console was cleared
And not clearing the console. Now in my scripts console.log's do not register and I'm wondering what is going on. 99% sure it has to do with the double percent signs (%%).
Anyone know what I did wrong or better yet, how to fix the console?
A bug report for this issue has been filed here.
Edit: Feeling pretty dumb, but I had Preserve log checked... That's why the console wasn't clearing.
As discussed in the comments, there are actually many different ways of constructing a string that causes this issue, and it is not necessary for there to be two percent signs in most cases.
http://example.com/%
http://%%%
http://ab%
http://%ab
http://%zz
However, it's not just the presence of a percent sign that breaks the Chrome console, as when we enter the following well-formed URL, the console continues to work properly and produces a clickable link.
http://ab%20cd
Additionally, the strings http://%, and http://%% will also print properly, since Chrome will not auto-link a URL-link string unless the http:// is followed by at least 3 characters.
From here I hypothesized that the issue must be in the process of linking a URL string in the console, likely in the process of decoding a malformed URL. I remembered that the JavaScript function decodeURI will throw an exception if given a malformed URL, and since Chrome's developer tools are largely written in JavaScript, could this be the issue that is evidently crashing the developer console?
To test this theory, I ran Chrome by the command link, to see if any errors were being logged.
Indeed, the same error you would see if you ran decodeURI on a malformed URL (i.e. decodeURI('http://example.com/%')) was being printed to the console:
[4810:1287:0107/164725:ERROR:CONSOLE(683)] "Uncaught URIError: URI malformed", source: chrome-devtools://devtools/bundled/devtools.js (683)
So, I opened the URL chrome-devtools://devtools/bundled/devtools.js in Chrome, and on line 683, I found the following.
{var parsedURL=new WebInspector.ParsedURL(decodeURI(url));var origin;var folderPath;var name;if(parsedURL.isValid){origin=parsedURL.scheme+"://"+parsedURL.host;if(parsedURL.port)
As we can see, decodeURI(url) is being called on the URL without any error checking, thus throwing the exception and crashing the developer console.
A real fix for this issue will come from adding error handling to the Chrome console code, but in the meantime, one way to avoid the issue would be to wrap the string in a complex data type like an array to prevent parsing when logging.
var x = "http://example.com/%";
console.log([x]);
Thankfully, the broken console issue does not persist once the tab is closed, and will not affect other tabs.
Update:
Apparently, the issue can persist across tabs and restarts if Preserve Log is checked. Uncheck this if you are having this issue.
Update 2:
As of Chrome 40, this issue is fixed.
I am doing an experimental HTML template wich comes with jquery.min.js file - one of the most popular javascript libraries.
When I load the template from my local hard drive it works fine.
When I upload it and load it from server (GWAN) I get error (I think is not the only one) in Chrome looks like this:
Uncaught SyntaxError: Unexpected token { jquery.min.js:3
I inspected a bit and realized there is a
function $
which was turned into
function$
by GWan. The space removed is causing an error in Chrome, Firefox and Safari. I haven't tested other browsers but my IDE also reports a syntax error in the downloaded from GWAN version of the JS file.
I have also tried uploading the files to another server (Apache) and no problem there. The js file was not modified...
Any clues on how to get over this? I suppose there is a bug in javascript on-the-fly optimization of GWan?
Thanks.
It's a known issue and it will be fixed in next release (soon)
You'll be able to disable minifying directly from a init.c script in G-WAN v4.10+, this way:
u8 *www_mini = (u8*)get_env(argv, USE_MINIFYING);
if(www_mini)
{
*www_mini = 0;
puts("> disable minifying");
}
You just have to wait for few days for the new v5 release.
I'm testing out a website that runs fine on Firefox (Win/Mac), Chrome (Win/Mac) and Safari. I'm having difficulty with Internet Explorer unfortunately. I get the following error message:
SCRIPT65535: Unexpected call to method or property access.
raphael-min.js, line 8 character 64961
I've taken a look at the debug output which looks like just takes me to a part of the Raphel library:
c=a.getScreenCTM()||a.createSVGMatrix()
I've searched for this error message online, but I don't understand what solution is relevant to this case as I've no idea what is causing the problem. I am also using the jQuery library. Are there any tests that I can do that can give me more information about the source of the problem?
I just found how to patch this, in order to keep the compressed version of Raphael.
Replace (don't forget the coma):
c=a.getScreenCTM()||a.createSVGMatrix(),
By that (dont't forget the end space):
c;try{c=a.getScreenCTM()||a.createSVGMatrix()}catch(e){c=a.createSVGMatrix()};var
Works fine ! :)
Means :
c; : declaration of variable c, and stop the first instruction.
try{c=a.getScreenCTM()||a.createSVGMatrix()}catch(e){c=a.createSVGMatrix()}; : our instruction, surrounded by a try/catch, to avoid IE error
var + a space : (don't forget the space!) allow us to continue to declare variable
I found out that it's an issue with compression (of the js file). I had the exact same issue and I had been searching for a solution. Guess what? I tried it with the uncompressed Raphael file and voila! No more issues. Compressed file needs a tweak, it seems.
I'm using jQuery for my app and I'm getting this error in IE:
Line: 13
Char: 9
Error: Expected Identifier, string or number
Code: 0
..well, as you can see, the error isn't quite helpful. How do you fix those weird IE errors? Is there any tool or a list of error descriptions that tells you what to fix?
Thanks
I would suggest looking at line 13 of your JS file to find out where the error is.
FWIW, the "Expected Identifier, string or number" error often occurs when you have a trailing comma in a list or object declaration. Firefox doesn't mind this, but IE does.
Here's an article on debugging javascript in IE. IE8 comes with a built-in debugger.
The IE Script debugger is quite OK.
But try Mozilla's error console first. It has sane line numbering. Maybe the errors are identical.
Make sure you have Microsoft Office installed
In IE, go to Tools -> Internet Options -> Advanced tab
From there UNCHECK "Disable script debugging (Internet Explorer)"
Then when a script creates an error, you will be presented with a dialog box:
Click the YES button to sign your life over to microsoft to start the debugger.
This is a really tedious workflow (the default sound that happens when a script bug is encountered is really annoying) so I don't think its a good way to work, recommend firefox error console over it any day.
See also.