I recently added JQuery's date-picker control to a project. In Internet Exploder, I get the following error message:
Internet Explorer cannot open the
Internet site
http://localhost/
Operation aborted
What is causing this problem?
There was a related question earlier today:
Operation Aborted Error in IE
This is a common problem.
It occurs in IE when a script tries to modify the DOM before the page is finished loading.
Take a look at what sort of scripts are executing. You'll find that something is getting started before the page is finished loading. You can use the window.onload event to correct the problem (or one of the onDomReady library functions).
Just elaborating Keparo's answer.
You can put your script inside one of the following functions(as per the library you are using) and that will resolve the issue.
prototype.js:
document.observe(’dom:loaded’, function () { /* your script goes here */ }),
jquery:
jQuery(document).ready(function () { /* your script goes here */ })
mootools:
document.addEvent(’domloaded’, function () { /* your script goes here */ })
Found this possibly related blog post: http://blogs.msdn.com/ie/archive/2008/04/23/what-happened-to-operation-aborted.aspx
Or this: http://weblogs.asp.net/infinitiesloop/archive/2006/11/02/Dealing-with-IE-_2600_quot_3B00_Operation-Aborted_2600_quot_3B002E00_-Or_2C00_-how-to-Crash-IE.aspx
Seems to be pretty common
I was able to fix this problem on a few pages I was having trouble with today.
If you have JavaScript that modified the DOM anywhere within the body of the page, try moving it below the </body> tag.
Example:
Change
...
<script>highlightSearchTerms();</script>
</body>
</html>
To
...
</body>
<script>highlightSearchTerms();</script>
</html>
This comes up a lot with Google Maps (used to drive me bonkers because it's hard to debug). One simple solution is to add the defer attribute to your script tags. They don't validate that way, but hey, this is real life we're talking about.
Related
Hello guys,
I have a strange problem with my ASP.NET 4.5 page. For some strange reason, my window.onbeforeunload function gets overwritten every time I load the page. Inside the debugger, I can clearly see that the right value is set in my head section, if I place a breakpoint there. However, after finishing the loading process of the site, the value changes to the following:
function (a){return typeof p!="undefined"&&(!a||p.event.triggered!==a.type)?p.event.dispatch.apply(h.elem,arguments):b}
I have no idea where this is coming from. This is my code from the head section of the page:
window.onbeforeunload = function (e) { return 'Do you really want to cancel?'; };
I'm using JQuery 2.1.3 as well as DevExpress 14.2 in my project. Any idea what could be responsible for this weird behavior?
Thanks in advance!
I actually found the answer where this is coming from thanks to #DavidTansey's hint. It's the Browser Link feature that was introduced in Visual Studio 2013. It looks like Browser Link uses some old jQuery library and overwrites various handlers.
So if you are having the same issue, please try to disable the feature (the menu is next to the browser selection in the tool bar). This should solve the problem.
I'm pretty sure that this problem wouldn't appear on a real server, because it would likely not use Browser Link.
I develop plugins for WordPress. It uses some jquery in the user side (themes) as a jquery plugin.
The problem is, when there is an javascript error with other plugins made by other autors, my plugin's javascript fails to execute.
And the worst thing is people consider that there is a serious fault with my plugin even though it works 100% fine with error handling conditional statements. But it is actually due to some other javascript syntax errors of some other WP plugin/theme authors.
Is there a way to continue execute my plugin JS ignoring other JS errors. Or can i have suggestions to handle this problem ??
Try :
window.onerror = function(){
return true;
}
That is if you can include this before the bugged script has been executed.
You should correct the old JavaScript error because it may create many problems, not for right now but for next time.
Put your JavaScript file / code at the top (before JS having error), and call it before JavaScript effected by other JavaScript code.
In case you need handle JavaScript exception at run time, best option is
try { /* run js code */ }
catch (error){ /* resolve the issue or bug */ }
You should be able to swallow any error using the error event:
$(window).error(function(e){
e.preventDefault();
});
I've never attempted this, but it should work in theory.
It should be noted that this probably isn't a great solution to your problem. It could be that your plugin is interfering with other plugins. It is, of course, possible that the errors are no fault of your own, but generally speaking (with publicly released plugins) not the case.
I encountered the same problem: There are a bunch of plugins out there that make too many assumptions and cause JavaScript errors on YOUR page, even when you are being a good citizen; these errors have nothing to do with your plugin.
There's no sense trying to handle errors in other plugins -- IMO it is better to be self-contained but resilient to their errors.
In my case, the errors were halting the jquery DOM ready event, and my JavaScript init code wasn't getting executed. The exact form of the error isn't important though -- the solution is just to fire on multiple events.
The solution for me was to have fallbacks in addition to relying on the jQuery DOM ready event:
I wrapped any code I wanted to fire on the DOM ready event into their own function -- e.g. my_hardened_init_action();
I added a function, my_hardened_init(), that only runs once. It calls my_hardened_init_action() the first time it is called, and does nothing on subsequent calls.
I added various methods to call my_hardened_init() in the WordPress footer. In my case, I only needed two. First, trying the usual jQuery DOM init, but falling back to a simple setTimeout(). So if the jQuery DOM init never fires due to broken JavaScript, the timeout will fire shortly after when the page has finished loading.
You could add multiple other fallbacks -- even add the code to the header if needs be. As my_hardened_init() only runs once, you can try as many times as you like to trigger it.
This has worked on a bunch of client sites with a range of other broken plugins.
Hope this helps.
What about window.onerror?
https://developer.mozilla.org/en-US/docs/DOM/window.onerror
<script>
var _z = console;
Object.defineProperty(window, 'console', {
get: function(){
if (_z._commandLineAPI) {
return true;
}
return _z;
},
set: function(val) {
_z = val;
}
});
</script>
If you page is running. Use:
$(window).error(function(e){
e.preventDefault();
}); // IGNORE ALL ERROR JQUERY!
or use:
window.onerror = function(){
return true;
} // IGNORE ALL ERROR JAVASCRIPT!
A regular try catch statements won't work for these types of errors.
Possible workarounds:
Use inline-css to float the bar to the left instead of jQuery (I am not sure what the full function of your plugin is but if it just floats the bar to the left why not just use css?)
Have a invisible iframe which tries to run some code on the parent page. if it fails than alert the user(from within this iframe) that it wasn't your fault :)
Perhaps you could try putting your js in an html object, so that it's executed in a separate page. That probably won't help much if the js on the main page wont run to interact with the object. Just something to play with.
Put your call to plugin in
try{
......
}
catch(e){
}
This is worked for me:
try{
//your code
}
catch(error)
{
return true;
}
I have a small code in my page with
<script type="text/javascript">
function doPost() {
document.forms["form"].submit();
}
function Func1Delay()
{
setTimeout("doPost()", 0);
}
....
<body onload="Func1Delay()">
I have this error in the console saying
Uncaught TypeError: Cannot call method 'create' of undefined
and on the right, it's due to the chrome extension MeasureIt. When I disable it, my script works. Is there a workaround for this problem?
The short answer is YES.
But the complete answer is NO, it's not Chrome, but some extension who interfere with your code.
For example:
1) A content script can add a listener and use stopPropagation. In this case your code won't receive that event. I can image a more specific scenario where the content script fails and therefore prevents other listeners to execute.
2) A content script can mess with your page's elements. It can remove some, and add its owm. What would happen if the extension add a SCRIPT element with a var or function named exactly the same that one of yours?
We cannot be sure about how "well" the extension's code is written.
By the way, there is a lot of Chrome's extensions that interfere with pages. Some months ago Skype extension for Chrome was found guilty of interfere and destabilize web pages and video playback in that browser.
I'm working on a screen reader project and I needed to get the paragraph under the cursor. To do that in Firefox, I wrote an extension, to which my screen reader connects through sockets and gets the text. I needed to get the current element under the cursor and the function worked fine in a sample html page written by myself (So there is no problem with the function).
But when I try to attach the function to my JS file in the extension, It seems that the function which is called by "document.body.addEventListener('mouseover',myfunc(mEvent),false);" is never called.
But if I call
document.body.addEventListener('mouseover',function(mEvent){...},true);
myfunc is called.
I'm new to javascript, so excuse me if it's a stupid question, But why the
document.body.addEventListener('mouseover',function(mEvent){...},true);
is not working?
I always appreciated your nice helps and ideas. :)
While this isn't a direct answer to your question, I hope that it is helpful nevertheless. Using an extension for a screen reader is unnecessary, in particular you might not want to update that extension regularly as the browser's user interface changes. Firefox supports a number of accessibility APIs which you can use directly from your application. These APIs have the advantage of being stable, once your implementation is done it should continue working (as far as I remember there was only one occasion where Mozilla broke compatibility with existing screen readers).
As to the actual question: you didn't tell anything about the context in which this code is executing. Normally, extensions run code in their XUL overlay meaning that the context is the browser window, not the web page. Which would explain why your code isn't working (it's a XUL document, no document.body there). What you probably mean is attaching an event listener to the <tabbrowser> element where the web pages are loaded: gBrowser.addEventListener(...). Side-note: If you really wanted to catch all events on a XUL document you should register an event listener on document or document.documentElement.
Btw, you can see error messages related to extensions in the Error Console (the article I link to explains how to enable it in the current Firefox versions).
There may be other issues here, but the syntax of your addEventListener call is incorrect and could be causing the issue you are seeing:
document.body.addEventListener('mouseover',myfunc(mEvent),false); is actually invoking "myfunc" at the same time you are invoking addEventListener and passing it as the second parameter.
You should instead be calling it this way:
document.body.addEventListener('mouseover',function() { myfunc(mEvent) },false);
Add height to a body element.
<html>
<style>
.vh {
height: 100vh;
}
</style>
<body class="vh">
<script>
document.body.addEventListener('click', () => {
console.log('mouse click');
});
</script>
</body>
</html>
I suspect that the document is not yet ready, so there is nothing to bind to. Try adding an onload="addMyEventListener();" to your <body> and see if that fixes things up. I don't know the proper way to time things, so maybe someone else can chime in with the best way to handle this.
following Wladimir Palant's advise, the follow is working:
document.addEventListener('click', function() { ... }, false);
I also had the same problem and now solved it. After closing tag, try adding an document.body.addEventListener. Parser didn't recognize DOM object of the "addEventListener" event because HTML tag of DOM object is not closed.
Refer to following. It works well.
<html>
<body>
...
</body>
<script type="text/javascript">
document.body.addEventListener('click', function() { ... });
</script>
</html>
I have a site that I put:
<body onload="ajaxLoad()" >
I have a Javascript function that then inserts data from my database into the text editor by using the setContent Javascript method of the textarea. It seems fine in Firefox and IE but in Chrome sometimes nothing shows up. There is no error, just a blank editor.
In the body section I have:
<textarea id="elm1" name="elm1" rows="40" cols="60" style="width: 100%">
</textarea>
In the head section I have:
function ajaxLoad() {
var ed = tinyMCE.get('elm1');
ed.setProgressState(1); // Show progress
window.setTimeout(function() {
ed.setProgressState(0); // Hide progress
ed.setContent('<p style="text-align: center;"><strong><br /><span style="font-size: small;">General Manager's Corner</span></strong></p><p style="text-align: center;">August 2009</p><p>It’s been 15<sup>th</sup> and so have a Steak Night (Saturday, 15<sup>th</sup>) and a shore Dinner planned (Saturday, 22<sup>nd</sup>) this month. urday, September 5<sup>th</sup>. e a can’t missed evening, shas extended it one additional week. The last clinic will be the week of August 11<sup>th</sup>. </p><p> Alt (Tuesday through Thursday) </p><p> I wouClub.</p><p> </p><p> </p><p> </p><p> <strong></strong></p>');
}, 1);
}
I am not sure if its some of the formatting that Chrome is rejecting but it seems like if TinyMCE can parse it in one browser, it should be able to do it in any browser, so I am confused.
Any suggestions?
Background:
For various reasons onload() is not considered the proper approach for loading Javascript, see for example Launching Code on Document Ready, with the most important/noticeable one being that Javascript code isn't run until the page has finished downloading entirely, including images and the like, which might take an eternity therefore (e.g. if an external banner ad server is down etc.).
Instead it is recommended to load Javascript as soon as the DOM is ready, but unfortunately there is no cross browser compatible native solution for this, see Getting notified when the page DOM has loaded (but before window.onload); please note that my entire answer is based upon the most excellent Javascript library jQuery, which offers a cross browser solution for this problem, consequently I'd definitely favor the two higher voted answers over the accepted solution myself.
Likely cause:
Your issue seems to be caused by the opposite behavior though: Chrome facilitates the WebKit rendering engine, just like Safari, and for the latter onload() is discussed to behave differently, see section When does onload fire? in Is Safari faster?. Another description of this problem specific to Chrome can be found in window.onload not working correctly in Chrome, without an explanation though.
In conclusion I suspect onload() to fire before the DOM is actually loaded completely, at least concerning the requirements of TinyMCE, which is notoriously fragile regarding issues like this and simply ceases to load.
Possible solution:
Just facilitating attribute defer on the script tag as outlined in window.onload not working correctly in Chrome is again not cross browser compatible, hence I'd simply go with the widely deployed and proven approach of using the already mentioned jQuery cross browser solution for the onload() problem, which is good practice anyway and should in principle take care of your inverse issue as well.
Update:
There are indeed some bugs filed against WebKit which could back my conclusion (no matter whether this behavior actually constitutes a bug or is intentional), see:
onload sometimes fired before all resources are loaded
window.onload fires before all subresources loaded
Window.onload is firing before image resources are loaded
I had a similar problem (editor not showing in chrome) and read in some forum, that if tinyMCE is unable to locate some files, it just stops loading. Try tracking down if everything is found using firebug's net tab (clear your cache first).
First of all; see to it that you have the latest version of TinyMCE.
I could not reproduce your problem given the information you provides. It seems just fine ( with the faked ajaxload ).
You could always try to go the "back entrance" in;
var myed = document.getElementById('elm1_ifr');
myed.contentDocument.getElementById('tinymce').innerHTML="<p style=\"text-align: center;\"><strong>hacking <span style=\"font-size: small;\">my</span> way in.</strong></p>";
Hope you good luck!
SOLUTION:
Ive been struggling with the TinyMCE toolbar not appearing in all kinds of secnarios....it would work in one user's IE browser, but not another. It would not work in Firefox or Chrome, etc.
Turns out if in the newest 3.3 version there are STILL bugs they have not fixed. This one occurs when in your webpage JavaScript code, where you instantiate the TinyMCE, if you added code for the plugin part where you load up two specific plugins, the toolbar fails to appear and you see HTML:
plugins:
"safari,spellchecker,pagebreak,style,layer,table,save,advhr,advimage,advlink,emotions,iespell,
inlinepopups,insertdatetime,preview,media,searchreplace,print,contextmenu,paste,directionality,
fullscreen,noneditable,visualchars,nonbreaking,xhtmlxtras,template,**imagemanager,filemanager**",
Remove all references to imagemanager and filemanager in your web page, then refresh your browser...
When you do, retest in Chrome and Firefox and IE and the TinyMCE suddenly appears! Wow....a miracle, huh?
Turns out their "main developer" hasn't fixed the issue but does explain it as such, if you want to try and still use those plugins and yet fix the problem. His quote is as follows:
"If the ImageManager/FileManager are old they might not use the new
scriptloader api. And the new 3.3 version will load all dependent
scripts async instead of sync. - Spocke - Main developer of TinyMCE"
There are a few ways to set content in a TinyMCE editor. If you want the content to be there when the page first loads, you can just put it between the tags.
Otherwise, you can do this through script in the following way:
window.onload = function() {
tinyMCE.getInstanceById("ProfileText").setContent('test');
};
I have wrapped the code in a window.onload block. If you have other functions that set content dynamically through this way after the TinyMCE editor has already loaded, then you do not need that.
There is an option oninit for the function tinyMCE.init(), put your method there:
tinyMCE.init({
oninit: function(){
tinyMCE.activeEditor.setContent('blah');
}
});
It works this way.
The editor is not fully loaded on document load event, as it the editor loader will post-load a bunch of files.
same problem here, ie needs
var ed = tinyMCE.get('content');
ed.setContent('zzz');
other browsers
document.getElementById("content").innerHTML="zzz";
i am quite disapointed
will need to check browser in javascript to get it working properly, thats suxx