Detecting cause of IE's Operation Aborted Issue - javascript

My site is suffering from the Operation Aborted error. What I find weird is that in my case the error only sometimes happens. The site has been running fine for three months then today it starts happening but not every time.
The page this is occuring on is rather large with a lot of third party controls. What I'd like is a tool that could pinpoint where the failure is occuring. Seems like the best I can do is find the first javascript error that occurs after the operation aborted; however, this doesn't help much. This failure is because an element of the dom isn't available which I'd expect since IE stopped parsing the HTML.
Any one have any ideas or tricks to narrow this down?
Edit
I appreciate additional ways to resolve the issue; however, what I am looking for is a way to identify which script is causing the issue.
Final Edit
After switching to IE8, I was able to determine the cause was the AjaxControl Toolkit's modal popup dialog. There was no concrete way to determine this which is dissapointing, but the debugger let me see where it was failing which was very consistent. Since there is no way in the control to tell it to move its initialization, I disabled it, and have the script to create the client side control in my document load event handler.
This issue is no fault of the control, it was occuring because the content for the popup is actually in a second form. Frankly I'm surprised it ever worked.

Do you have any javascript that is manipulating the DOM, as the case is described at http://support.microsoft.com/kb/927917#more_information ?
Try moving all script blocks to the very bottom of the page, just before the </body> tag, and don't try to set the innerHTML property of the body tag itself.
If the problem is with javascript executing before the DOM is fully built, try moving any initialization calls into a function that will run only after the page is fully loaded. So, instead of something like this:
<div class="myWidgetControl"/>
<script type="text/javascript">
initializeWidgets();
</script>
Try something like this:
<div class="myWidgetControl"/>
<script type="text/javascript">
$(document).ready(
function () { initializeWidgets(); }
);
</script>

You can use script provided by IE Blog to investigate the problem. See: http://blogs.msdn.com/ie/archive/2009/09/03/preventing-operation-aborted-scenarios.aspx

This is a nifty trick I used (based on the link in the JS comments below) that completely avoids the Op Ab error without affecting performance in other browsers. You first wrap whatever script you're doing that can cause the error (for instance, loading/instantiating a 3rd-party widget) in a function, then call that function within the delayExecutionForIE function -- note that the call to myFunction is in there twice, once for IE and once for nice browsers.
Your 3rd-party script might prevent this working, depending on exactly what it does and how it expects to be loaded, but it's definitely worth a try.
function delayExecutionForIE() {
if ( typeof document.all == "object" &&
(document.readyState != "loaded"
&& document.readyState != "complete")
) {
try {
//If IE is used, use the trick by Diego Perini
//http://javascript.nwbox.com/IEContentLoaded/
document.documentElement.doScroll("left");
myFunction();
} catch(error) {
setTimeout(delayExecutionForIE, 200);
}
} else {
myFunction();
}
}
function myFunction() {
//this is your function that manipulates the DOM
}
delayExecutionForIE();

in the most cases it is a DOM issue in JS.
$( element ).append( someHtml );
so in IE you can add content to a object only if it has it's closing tag
For example the code below will cause the IE7 to bring the message "Operation aborted"
<div id="o">
...
$(o).appendChild();
...
</div>
And the right way
<div id="o">
...
</div>
$(o).appendChild();

Although IE8 will no longer cause that error to "crash" the rendering entirely, instead logging an error, it is unfortunately not caught by the JavaScript debugger found in the new Developer Tools, and the error message doesn't tell you where the error really occurred.
A workaround, which is certainly tedious, but could locate the issue, is to use IE8's debugger to put a breakpoint on the very first piece of JavaScript code that is run, and then continue hitting the "Step" button until the error icon pops up in the bottom left corner of the browser. When that happens, you know the line of code that causes the error was the one highlighted just before you clicked step. It's likely to be quite a bit of code you'll be stepping through, though, but I can't think of anything else (well, except contacting the vendors of that 3rd party code and seeing if they have any updates that might be related).
Of course, you could just tell your users to upgrade to IE8. ;)

And Microsoft does recommend upgrading to IE8!

Related

Member not found error in java script

The below code for opening and closing a window is throwing a java script error 'Member not found'. This does not happen in all machines but for certain users with IE 8.
winobject.blur() in the following code is throwing the error.
var winobject=null;
winobject = window.open('URL','Name',"width=1,height=1,top=2000,left=2000");
if(winobject!=null){
winobject.blur();
self.resizeTo(screen.availWidth,screen.availHeight);
winobject.close();
...
}
Any help or suggestion to resolve this issue?
Some additional observations- This issue only occurs when a window with the 'Name' already exists. Lets say if the user has already closed the pop up window that was already opened then the code will run fine. Also if I add one more window.open under the current one then no exception gets thrown when blur() is invoked. Not sure why though ?
if (typeof winobject != "undefined")
I just had an issue with something like this at work today. give that a try, you should be good to go.
Edit:
I have found the following link which appears to explain what is going on. Because you are creating that window on your own, IE8's "security" is preventing many common actions on it.
My next suggestion as a workaround would be to surround both the winobject.blur() and winobject.close() with if (winobject.blur) and if (winobject.close()) conditionals. Note that you do not have the parenthesis after blur and close in the if's, as you are looking for the presence of the method as opposed to calling the method.
Unfortunately, I'm not sure what the alternatives are that you can use to obtain the same effect. But that should hopefully prevent the error from being thrown.

How to detect where JavaScript alert is coming from?

I am trying to debug a very complex IE Intranet application. I am getting an alert with a custom message stating that an exception has occurred. I would like to find out more information about this exception as the message is not very helpful.
There is a master page which contains a lot of iFrames (and .htc files if that makes a difference) so I don't think that I can try and hijack window.alert. My last resort will be to try my luck with a file search.
Using IE 8, is there anyway I can detect where this alert is coming from? The ideal solution would be to somehow create a "breakOnAlert" function which inserts a debbuger statement at the correct alert location.
To clarify: The master page contains many iframes and I believe that the error+alert is coming from one of these. Each iframe is an aspx page (sometimes with dynamic html/javascript from the user) and contains inline and external JavaScript. Before posting I did try overriding alert in my page (a child page inside an iframe) but it didn't work. I am assuming that It doesn't work as each iframe has their own window object so they each have their own version of alert. For this to work I would need to find all iframes and override it for each one, something which I think would be very complicated to do. In the IE developer tools I can see a huge amount of script files (inline and external), so it would be very difficult to manually look for the alerts in there.
Since it's a real chore to do it in all iframes, I'd probably use Fiddler and programatically replace alert( with something like:
(function(n){alert(n);debugger;})(
IE should support the debugger statement, so you'd have a call-stack
This page explains how to do a text-replace in Fiddler
Example Fiddler custom rule to add to OnBeforeResponse:
if (oSession.oResponse.headers.ExistsAndContains("Content-Type", "html"))
{
oSession.utilDecodeResponse();
var oBody = System.Text.Encoding.UTF8.GetString(oSession.responseBodyBytes);
oBody = oBody.replace(/alert\(/gi, "(function(n){alert(n);debugger;})(");
oSession.utilSetResponseBody(oBody);
}
Ovveride alert function and set a breakpoint inside, then you can watch Stack Trace :)
function alert(message) {
var x = 'whatever';
}
$(function () {
alert('test');
});

Page load in IE, page includes flash banner

So here is the problem.
I have a flash banner consisting of two swf's which talk to each other through LocalConnection and also call external JS functions. (I haven't figured out whether this is important or just a coinsedense.)
I also have an external JS file, which tells the banner what to do through flashVars. And has the function which the banner calls on events.
As you can imagine this works everywhere allright except IE.
In IE I expirience this problem: I try to load a test page, which has a lot of pictures and a heavy background (so it takes a while to load). And i place the banner, which is added whith javascript before all that content. Something like this:
http://pastebin.com/nnTuPPhN
And sometimes usually on reload some pictures just do not appear. All text appears though.
I did try do dig through the script, but since it's not my script it prooved to be a bit difficult, finally I came to a conclusion that even though I don't like some parts of it, there are no apparent problems with it.
FireBug and Chrome, Safari, Opera debuggers show no errors of any kind.
Now as last resort I added this to my JS file
window.onload = function()
{
alert('The page has loaded completely');
};
The outcome is that when i see all the pictures i see this message, when i don't i don't. It's doesn't help to wait for the pictures to load.
I have also found this topic:
window.onload() is not firing with IE 8 in first shot
which talks about similar problem, so it would be nice if anyone specifies what addon can cause this? QUOTE: One of the IE addons created this problem, after disabling its working fine. Thanks for your time and answers :)
As long as it isn't the flash plugin=)))
I do check for flash plugin on page this way:
var ad_checkPlugin = function(){
// From SWFObject v2.2 <http://code.google.com/p/swfobject/>
if (typeof navigator.plugins != "undefined" && typeof navigator.plugins["Shockwave Flash"] == "object")
{
d = navigator.plugins["Shockwave Flash"].description;
return (d && !(typeof navigator.mimeTypes != "undefined" && navigator.mimeTypes["application/x-shockwave-flash"] && !navigator.mimeTypes["application/x-shockwave-flash"].enabledPlugin))
}
else if (typeof window.ActiveXObject != "undefined")
{
try
{
var d = new window.ActiveXObject("ShockwaveFlash.ShockwaveFlash").GetVariable("$version");
// new window.ActiveXObject(...) will return null if ActiveX is disabled
return d?true:false;
}
catch(e)
{
return false;
}
}
}
And there was another way which caused the same problems in Ie, so i guess it's not the problem with the plugin check.
I would be happy if you tell me general things which can cause such problems, i can also ad the script if you guys ask for it.
And i will be even happier if you tell me specific things=)) , if you're going to say that problems lie whithin the script I will no be able to agree or disagree I've cheked and see no problem, browsers see no problems too. But it must be there somewhere since it doesn't work.
UPDATE: I also have alerts every where in my JS now, now what i witness is this: in FF for example sometimes i see the alert
alert('The page has loaded completely');
but I am not left any time to click this one(click ok), when another alert pops up. Is that a normal thing for alerts? I should add that many of the alerts are in function called by the banner.
UPDATE no2:
I've isolated the problem even more I stopped any calls from flash to JS functions at all (First i tried to replace them with alert("hello world"); that didn't help the loading problem).
Now when flash doesn't call to JS the page loads just fine. Of course i need the flash to call external functions.
Anyway NEW QUESTION : could javascript called from flash make IE think that everything is loaded and it can stop, that is can it be something like:
clean your room (and two seconds later)
now brush your teeth
result: the room is half clean but the teeth are
I might add that whatever loads on the page, some things load always: text, spaces fo future pictures but that may just be a coincedence, apart from this there is no system at all to what has, and what hasn't loaded.
---------------------------> ANWSER FOUND
Thanks))) for voting for my question, and here is the anwser guys! The function used in flash namely
getURL("javascript: ...","");
is what actually stops the page from loading! Hm, rather than this it's better to use ExternalInterface(); I'll point out we are talking about AS 2.0 in AS3.0 there is no question that ExternalInterface should be used, since getURL is now navigateTo or smthg.
Thanks to the guy who wrote this AS to realise what the problem was=)
Just copying anwser from above so the question is solved
The function used in flash namely
getURL("javascript: ...",""); is what actually stops the page from
loading! Hm, rather than this it's better to use ExternalInterface();
I'll point out we are talking about AS 2.0 in AS3.0 there is no
question that ExternalInterface should be used, since getURL is now
navigateTo or smthg.

Is it ok to manipulate dom before ready state?

This is generally how I manage progressive enhancement whilst keep the experience clean, but how safe is it? is there potential for a race condition and this not working?
Imagine the simple abstract scenario, you want to display something differently if you have javascript support.. this is generally what I will end up doing:
<div id="test">original</div>
<script type="text/javascript">
var t = document.getElementById('test');
t.innerHTML = 'changed';
</script>
Many may claim you should use a framework and wait for a domready event, and do changes there.. however there is a significant delay where the 'test' element will have already been rendered before the end of the document and the css are ready and a domready triggers.. thus causing a noticable flicker of 'original'.
Is this code liable to race condition failures? or can I guarentee that an element is discoverable and modifiable if it exists before the script?
Thanks in advance.
You can, but there are issues surrounding doing it.
First off, in IE if you attempt to manipulate a node that has not been closed (e.g. BODY before its close tag which should be below your JS) then you can encounter IE's "OPERATION ABORTED" error which will result in a blank page. Manipulation of a node includes appending nodes, moving nodes, etc.
In other browsers the behavior is undefined, however they do usually behave as you would expect. The main issue is that as your page evolves, the page may load/parse/run differently. This may cause some script to run before a browser defines referenced elements have actually been created and made available for DOM manipulation.
If you are attempting to enhance your user perceived performance (i.e. snappiness). I highly suggest that you avoid this path and look into lightening your pages. You can use Yahoo's YSlow/Google's Page Performance Firebug to help you get started.
Google's Page Speed
Yahoo's YSlow
You can manipulate the DOM before it has fully loaded, but it can be risky. You obviously can't guarantee that the bit of the DOM you are trying to manipulate actually exists yet, so your code may fail intermittently.
As long as you only modify nodes which preceed the script block (ie the node's closing tag preceeds the script's opening tag), you shouldn't encounter any problems.
If you want to make sure the operation succeeds, wrap the code in a try...catch block and call it again via setTimeout() on failure.
In Viajeros.com I have a loading indicator working since 8-9 months and I have no problems so far. It looks like this:
<body>
<script type="text/javascript">
try {
document.write('<div id="cargando"><p>Cargando...<\/p><\/div>');
document.getElementById("cargando").style.display = "block";
} catch(E) {};
</script>
Accessing the DOM prematurely throws exceptions in IE 5 and Navigator 4.

Making Firebug break inside dynamically loaded javascript

I'm looking for a way to debug a dynamically loaded jQuery document.ready function.
Obviously I can't just bring up the script panel and add a breakpoint with the mouse since the function does not exist there.
I've also tried adding "debugger;" to the function (without the quotes), but that did not do anything. I have ensured that the function is actually executed while I tried this.
Thanks for your help,
Adrian
Edit: I just noticed that Firebug actually breaks on debug. However, when it does so on a dynamically loaded script, it does not bring up the source code of that script as usual. Plus, the call stack ends right below my own code. I can bring up the implementation for document.ready via the call stack, but that does not really help. Is this a Firebug bug or have I missed something?
I just worked on this similar question. The solution involves adding the word debugger twice; once at the top of the external file and one more time at the top of the function that needs to be debugged.
I noticed that if the debugger word was used only once, it did not work. Example:
//myExternal.js
debugger;
function myExternalFunction(){
debugger;
/* do something here */
}
You might try placing a break point where the event is called, and then instead of click "Play", choose "Step Into" (F11). I don't have a test case in front of me, but I think this may work.
I don't know if you ever got this figured out, but in case someone else needs it...
I got around this by moving the code I wanted to debug to an external file that was linked from the main page.
In my case, I had default.aspx loading services.aspx into a content div using jQuery AJAX. Services.aspx in turn, was loading jQuery UI tab elements using AJAX from a webservice that was providing it data. The webservice code was in a file called data.js which was linked from default.aspx. I needed to debug the code that was in the header of services.aspx (that loaded the tabs with data), but couldn't ever see it in any of the available inspectors. I just moved the code I needed to a new function in data.js and called it from the header in services.aspx.
I hope that makes sense to someone who needs it!
Just encountered same behavior (Firebug ignoring debugger; statement in dynamically loaded code) in Firefox 5.0/Firebug 1.7.3.
Worked around by detaching Firebug window ("Open Firebug in New Window").
There's also a 'debugger' keyword that's supported by the IE JScript debugger, and Safari's Web Inspector, so i would be surprised ifit wasn't supported in firebug.
Basically:
// mydynamicallyloadedfile.js
... // do stuff
debugger; // triggers debugger
... // more stuff
And i would expect firebug to break at the debugger keyword

Categories