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');
});
Related
I am Developing the Politics & Information Google Chrome Extension but I have run into a problem, I am attempting to insert a JS Script into one of the div's of the Webpage, the result is nothing, absolutely nothing pops up
I know i have the right area because if I use += "Hello"; it displays the text there properly, but when I actually do +="" the script doesn't seem to run. To all them devs out there, any suggestions?
How I am doing it:
theinfotable.children[0].innerHTML += '';
JavaScript (Google Chrome Extension inserted from the Contentscripts.js file)
I can see that the Code Inserted, but the script still doesn't seem to load: (And I know this code works when I have my own page instead of inserting)
http://oi61.tinypic.com/2irkx9c.jpg
Rather than use .innerHTML, have you tried creating a new element and appending it?
var injectable = document.createElement("script");
injectable.innerHTML = "console.log('Injected!');" // Your script here
// or injectable.src = "location" if you'd rather link
theinfotable.children[0].appendChild(injectable);
I'm not entirely sure why this occurs, if I had to guess it's an idiosyncrasy in how things are parsed or a security measure, but appendChild should do the trick. Basically, from what I understand it's the difference between
innerHTML +=: converting HTML to a string, and adding to that string, and re-parsing that string with new content
and...
appendChild: creating a DOM node, appending said DOM node, recalculating/refreshing the document for styling recalculations.
And somewhere in the parsing, your new script info is ignored.
I figured out the problem, the page was blocking my script as "Insecure" at the top right there was a little Shield Icon and after clicking on it I just had to put "Show Insecure Scripts" and it popped up.
(If anyone feels like telling me so people don't have to do this, that'd be great :D) I would rather people just have it pop up instead of having to stay for it to pop up
How can I find the specific code that's causing a web page to auto-refresh?
I've looked through the source for an HTML meta-refresh, to no avail. I also can't find any Javascript "reload" in the main page, leading me to think it's perhaps externally loaded through a link javascript file.
How would a "pro" track this down, like through Firebug (or other debugger)?
Note:
I'm more interested in the process of being able to debug and track down something like this, rather than a "catch-all" solution that will stop it cold (such as disabling the Firefox-wide ability for pages to auto-refresh themselves).
The problem is most likely in a javascript file. Go through them looking for the below:
1) Look for anything that can be used to change the URL/location, redirect, or cause browser to go back:
window.location.href
window.history.back(-1)
window.navigate(”example.html”);
self.location=”top.htm”;
top.location=”error.jsp”;
2) Look for timers such as:
setTimeout()
setInterval()
3) Look for broken selectors. You may have click event handlers attached to whole DIVs, or even the whole document by accident.
There is no straightway to find the source of the refresh in javascript. Try #Steve Papa's tips on your code.Incase you want to prevent the refresh and see in the console if you can find any useful info.
To stop the refresh, use onbeforeunload event. The event object passed to the event has lot of info, but I couldnt find anything which points to the trigger. Add a breakpoint on closeIt(e), and look for clues in global variables or call stack(which i dont think will be of much use here).
function closeIt(){
return "Any string value here forces a dialog box to \n" +
"appear before closing the window.";
}
window.onbeforeunload = function(e){
closeIt(e); //add a breakpoint here.
}
setTimeout(function(){location.reload()},2000);
http://jsfiddle.net/Gjuhm/4/
I have a pop-up CustomControl which I use in a large-scale web application. The pop-up works well everywhere other than when used inside an asp:UpdatePanel, the problem arises when controlling the visibility of the pop-up (the pop-up is nested in a table) with other controls:
When I click the button to open the window I get Error: Object expected and when I try to debug the error with IE 8 JSEditor I get ``Source Code is not available for this location.
I believe that the code of the pop-up is not being initialized completely, but it is just my guess and I don't know how to resolve this issue.
Any help or ideas will be appreciated.
While I can't get to see that question title has a lot to do with the subject at hand,
Most (if not all) Object Expected error occurs when you add a reference on your page to a JavaScript file which doesn't exist or cannot be opened.
When you run your website in debug-mode, VS will put another pseudo-project in solution explorer, navigate through the files there and you will find the already loaded-version of JS, you can set breakpoints there and see what code exactly is "not available".
Note: This is for Web Applications, I'm not sure if it applies to Project-less Websites.
Does this work in other browsers? Have you tried Firefox and Firebug to investigate the issue or is this specific to IE.
Having code in an ASP:UpdatePanel means that the Microsoft Ajax javascript include will be loaded and come an interfere with the object model you are normally expecting to get. Are you certain of the id or name you are trying to find as this might not be returning an Object hence the error.
I have used jQuery and classes and styles to add behaviour after the page loads to avoid id issues. The $jQuery.live() function is useful to ensure handlers get bound to items delivered to the page with MS Ajax.
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!
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