I realise this is not the ideal place to ask about this in terms of searchability, but I've got a page whose JavaScript code throws "Stack overflow in line 0" errors when I look at it in Internet Explorer.
The problem is quite clearly not in line 0, but somewhere in the list of stuff that I'm writing to the document. Everything works fine in Firefox, so I don't have the delights of Firebug and friends to assist in troubleshooting.
Are there any standard causes for this? I'm guessing this is probably an Internet Explorer 7 bug or something quite obscure, and my Google-fu is bringing me little joy currently. I can find lots of people who have run into this before, but I can't seem to find how they solved it.
I ran into this problem recently and wrote up a post about the particular case in our code that was causing this problem.
http://cappuccino.org/discuss/2010/03/01/internet-explorer-global-variables-and-stack-overflows/
The quick summary is: recursion that passes through the host global object is limited to a stack depth of 13. In other words, if the reference your function call is using (not necessarily the function itself) was defined with some form window.foo = function, then recursing through foo is limited to a depth of 13.
Aha!
I had an OnError() event in some code that was setting the image source to a default image path if it wasn't found. Of course, if the default image path wasn't found it would trigger the error handler...
For people who have a similar problem but not the same, I guess the cause of this is most likely to be either an unterminated loop, an event handler that triggers itself or something similar that throws the JavaScript engine into a spin.
You can turn off the "Disable Script Debugging" option inside of Internet Explorer and start debugging with Visual Studio if you happen to have that around.
I've found that it is one of few ways to diagnose some of those IE specific issues.
I had this problem, and I solved it. There was an attribute in the <%# Page tag named MaintainScrollPositionOnPostback and after removing it, the error disapeared.
I added it before to prevent scrolling after each postback.
If you came here because you had the problem inside your selenium tests:
IE doesn't like By.id("xyz"). Use By.name, xpath, or whatever instead.
Also having smartNavigation="true" causes this"
I set up a default project and found out the following:
The problem is the combination of smartNavigation and maintainScrollPositionOnPostBack. The error only occurs when both are set to true.
In my case, the error was produced by:
<pages smartNavigation="true" maintainScrollPositionOnPostBack="true" />
Any other combination works fine.
Can anybody confirm this?
Internet Options
Tools
Internet options
Advanced
Navigation section
Click > Disable script debugging
display a notification about every script error
sign in
You will smile !
My was "at line 1" instead but...
I got this problem when using jQuery's .clone method. I replaced these by using making jQuery objects from the html string: $($(selector).html()).
I have reproduced the same error on IE8. One of the text boxes has some event handlers to replace not valid data.
$('.numbersonly').on("keyup input propertychange", function () {
//code
});
The error message was shown on entering data to this text box. We removed event "propertychange" from the code above and now it works correctly.
P.S. maybe it will help somebody
I don't know what to tell you, but the same problem occured with jQuery table sorting and SEARCH.
When there is nothing left in the table, where you are searching a string for example, you get this error too. Even in Google Analytics this error occurs often.
In my case I had two functions a() and b(). First was calling second and second was calling first one:
var i = 0;
function a() { b(); }
function b() {
i++;
if (i < 30) {
a();
}
}
a();
I resolved this using setTimeout:
var i = 0;
function a() { b(); }
function b() {
i++;
if (i < 30) {
setTimeout( function() {
a();
}, 0);
}
}
a();
This is problem with Java and Flash Player. Install the latest Java and Flash Player, and the problem will be resolved. If not, then install Mozilla Firefox, it will auto install the updates required.
Related
I run in Chome devtools next code
(function() {
var a = 5;
debugger; // when I stop here I evaluate `a = 9`
console.log(a);
})(); // and got 5
but if I use
(function() {
var a = { a: 5 };
debugger; // when I stop here I evaluate `a.a = 9`
console.log(a.a);
})(); // and got 9
Why?
PS
also why it doesn't work in FF / Safari (it even didn't stop in debugger line )
This is behavior is simply a bug, and will be fixed in an upcoming release.
If you want a "why" deeper than that, you'll need to know a lot about Chrome's debugger and JavaScript implementation. According to the diff of one file in the fix, the debugger formerly used a context_builder.native_context but now it uses a context_builder.evaluation_context. Apparently the native_context created by the old debugger code had trouble resolving (or not treating as read-only) local-scope variables. If you really wanted more, you could contact the author of the fix.
As for why the debugger does not appear in Firefox: it will appear if you are running code from a <script> and have your dev tools open. When running code from the console, it appears that you must have the debugger tab open specifically. Obviously, this is not possible if you have the console open to type in your code, but you can wrap it in setTimeout and quickly switch to the Debugger tab:
setTimeout(function() { debugger; }, 5000)
It is a matter of how the variables are used. Objects are used by reference. So changing a.a will effectively change the value at the proper memory address. Though, changing a itself in any of your test version won't do anything because a new memory address is created for the variable evaluated in the console.
For FireFox not breaking at debugger line, it states in this page (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger) : "If no debugging functionality is available, this statement has no effect.". So, you have to ensure FireBug is installed I presume.
I have a 17000 line page with lots of HTML/JavaScript/jQuery and it's always frustrating when I make a typo and there's no clue when the page loads into the browser what the problem is. It just - doesn't do anything. Consider the patch of code below, for example, where the third line terminates with a ' instead of a ; .
$(document).on('click', 'input#answer_chkbx', function(e) {
if(e.target.checked){
x$ = g.currentElement$.find('.cellContent')'
g.currentElement$.addClass('answerBox')
.css('background-color','tansparent')
.height(25)
.width(150);
}
});
There should be something that runs through the code and finds that immediately.
Is there a way to check for things like this?
Thanks
You might consider a tool such as JSLint or JSHint.
For offline coding you can use Netbeans IDE or Dreamweaver
I have this script provided by #Felix Kling in this post HERE, but is crashing my IE when I use it; on FF 3.6, Opera, Chrome, Safari work fine.
Any idea why is this happening? A fix maybe?
var ajaxTimeout;
function autorun() {
if ($("#contactForm").is(":visible")){
if(ajaxTimeout) {
clearInterval(ajaxTimeout);
ajaxTimeout = false;
}
}
else if(!ajaxTimeout) {
ajaxTimeout = setInterval("refreshAjax();", 15000);
}
}
$(function autorun() {
setInterval("autorun();", 2000)
});
Thanks,
Cristian.
LE. Sorry, forgot to add details about that.
IE just closes, "encounter an error and needs to close, looking for a solution ...". IE 8.0 Windows7. If I load the page, I cannot open the debugger from the developer tools, but if I open the debugger before I load that page and press Start debug it doesn't show any errors or anything, but the page is not refreshing the grid as it was suppose to.
Here's what you're after:
$(function () {
var ajaxTimeout;
function autorun() {
if ($("#contactForm").is(":visible")){
if(ajaxTimeout) {
clearInterval(ajaxTimeout);
ajaxTimeout = false;
}
}
else if(!ajaxTimeout) {
ajaxTimeout = setInterval(refreshAjax, 15000);
}
}
setInterval(autorun, 2000);
});
IE doesn't at all like named functions used like this, and it's overriding the previously defined one. This is a long-standing bug not fixed until IE9. The core of the problem is that $(function autorun() { is taking over the autorun name, which is just queuing more and more runs of itself.
Also, it's better to pass function references to setInterval() directly, not strings.
I suspect that this is the culprit:
$(function autorun() {
setInterval("autorun();", 2000)
});
That's not really valid javascript. I think it's probably supposed to be something like:
$(document).ready(function() {
setInterval("autorun();", 2000);
});
[edit: there was an error in my suggestion above, and I have corrected it. I was incorrectly assigning the result of setInterval(...) to the variable ajaxTimeout. This ultimately caused the logic inside the main autorun() function to never initiate its interval on refreshAjax(), thus causing the code to appear to "do nothing".]
[edit: some have indicated that my suggestion was offered without enough explanation, so I'll try to provide that here.]
you were declaring function autorun() twice. Once at the top, and again in the bottom section where I've suggested that you should make changes. Both declarations are in the same scope, so the names will collide and behavior will be browser-dependent. Some browsers will let one function "hide" the other, while other browsers will (probably) refuse to compile it.
you have used a named function declaration (the second declaration of autorun) in an "inline" context. This may be allowed by some browsers (and some have suggested that it is actually valid by the standard -- though admittedly I thought it was not), but it will definitely cause problems in IE.
My suggestion changes the second declaration into an anonymous declaration so as to kill two birds with one stone: avoid a name collision, and use syntax that is supported across all browsers.
finally, I introduced the use of $(document).ready(...), because it's standard practice these days, when programming with jQuery. You can read more about it on jQuery's site. Long story short - it is directly equivalent to the $(function() {...}) syntax that you've used, so you can take it or leave it as you please.
My problem is that I'm using the CKEditor 3.4 plugin for jQuery, and it's giving me an error in IE 7+8 when executing a $(selector).val(html) call on the editor:
The error:
'this.$.innerHTML' is null or not an object
...which when run in the debugger, points to this line of code in the huge CKEditor.js:
getHtml:function(){var i=this.$.innerHTML;return c?i.replace(/<\?[^>]*>/g,''):i;}
...which translates to this in the source:
getHtml : function()
{
var retval = this.$.innerHTML;
// Strip <?xml:namespace> tags in IE. (#3341).
return CKEDITOR.env.ie ? retval.replace( /<\?[^>]*>/g, '' ) : retval;
},
My offending code (stripped down, but still giving the error):
var editor_data = $("textarea#body").val();
$("textarea#body").val(editor_data);
... and the textarea code for posterity:
<textarea name="body" rows="15" cols="50" class="wysiwyg" id="body"></textarea>
I've tried reproducing in jsFiddle in IE8, but the strange thing is that it works as intended there. I'd love to also provide a working sample but I unfortunately cannot for reasons outside my control.
I've also tried this fix, and it cleared up the error issue, but after that setData did not work as intended and just overwrote the editor contents with nothing. I'll admit this problem+fix is a bit over my head...: http://dev.ckeditor.com/ticket/4566
(Sorry, long post :S) I've also tried to use the direct JavaScript API into CKEditor (abandoning the jQuery integration) and it threw the same error.
Anyone have anything they'd like me to try to fix this issue, or have any hunches of what it might be? It would be much appreciated!
Personally I'm not a fan of the existing answer that consists of modifying the source code because as soon as you update ckEditor, then you have to remember to modify the source yet again. I was having the same problem as the original poster and found a fix that is considered a hack, but totally usable. Simply, a Try/Catch made it all nice and happy in IE8. Now to test in IE7. The other bonus of this fix is that you're not left with blank data when it fails but that you get actual content you were trying to retrieve.
var editor = $('textarea.editor').ckeditorGet();
var vPageContent = "";
try{
vPageContent = editor.getData();//function call fails here
} catch(err){
vPageContent = editor.getData();//but will work here
}
May not be the best solution but take a look at this:
http://dev.ckeditor.com/ticket/4566
It claims that replacing
getHtml:function(){var i=this.$.innerHTML;return c?i.replace(/<\?[^>]*>/g,''):i;},
with
getHtml:function(){return (this.$) ? this.$.innerHTML : "";},
will solve the problem.
I'm not claiming this is the correct answer but I had the same problem today and (for now) it seems to work.
be careful with extra comma. IE does not like exra commas. You can check your code for extra comma with json lint
This may be dumb question. But somehow this engaged me for sometime and after some basic research I couldn't find an answer.
I was learning JavaScript and a code I wrote had an error and has been outputting infinite loops of alerts. I tried the normal shortcuts like Ctrl + C and Ctrl + Z but they didn't work. So I was thinking if there is any solution to this other than ending the browser process (like by doing a Ctrl + Alt + Del).
There are workarounds, as #Sarfras mentions, but no magic button that'll save you. The F5 workaround is the best I know of.
If you are using firebug, I would suggest you look into using the log feature rather then alerts. Many people find this as a useful way of debugging.
http://getfirebug.com/logging
If you are using alert as a debugging method, I strongly suggest you use the firebug plugin.
With it, you can use console.debug("whatever message", whatever, values).
Otherwise, if your intent is to actually use a dialog message, you could use some of these dialogs rather than the browser's built-in dialogs. Besides being a standard way of showing messages, they are way nicer ;)
You can log errors without a specific browser, with a global array.
This method allows you to 'turn off' an infinite alert,
but still be able to read the error log.
var logErrors= true, errorLog= [];
function Yikes(str){
if(str.constructor==Error)str=str.message;
errorLog.push(str);
if(logErrors== true){
logErrors= confirm(str+'\n keep showing errors? ');
}
return true;
}
window.onerror=Yikes;
you can also use it around problem code,
to return values:
try{
d2= Date.fromUTCArray(D.slice(0, D.length));
}
catch(er){
return Yikes(er.message+', '+D);
}