Since upgrading to Firefox 4.0, I've noticed that I'm occasionally getting an error in the console stating:
attempt to run compile-and-go script on a cleared scope
The only information I can find about this on the net currently is on the mozilla groups forum, where it is suggested that it's something to do with session restoring. In my case, though I haven't been able to reliably reproduce the error, it happens at any time, not just after a restore.
What's the deal? How do I stop the error?
I have noticed that if I disable the cache, I no longer get this error in the console.
I got this error when I tried adding events on elements appended from a same domain iframe. Added clone() and errors stopped.
In my case, it was
document.write
method causing the problem on Firefox 4, 5, 6 on Windows. Linux versions are unaffected. What I had to do is to overwritedocument.write
method.I aware that
document.write
shouldn't be used these days, butdeployJava.js
, a standard Java Applet deployment script written by Sun/Oracle, is using it. Google is using it in Google AdSense ads.document.write
is everywhere.I hope this helps. However, I saw lots of "solutions" on the Internet that didn't work for me. It may mean that "Attempt to run compile-and-go script on a cleared scope" is a Firefox JavaScript engine problem/bug.
Check your code for duplicated meta cache-control and remove one of them:
I've noticed that this error can happen if you write to the document with document.write after the document has completed loading (e.g. in a function called from JQuery's $(document).ready() method). When this happens, it seems that Firefox discards the old document and writes a new one. I don't know if this is new behavior or not. It seems that when you try to operate on the old document, e.g. with JQuery selectors, you get this error. For me, fixing the script in question to not call document.write after the document had loaded fixed the error.
It has nothing to do with firebug. The reason it "goes away" when firebug is disabled is that you are no longer seeing the exception. The cause of this is having an handler attached to an event that is now null but not properly cleaned up. You need to make sure that handler is properly disposed of, otherwise the event still fires the reference to the handler.