How to pause JavaScript execution in Internet Explorer?
Question
I have the following scenario:
- Main page
- Nested page
- Common JS file (which is included in both pages)
The nested page is subsequently loaded into an iframe of the main page. Both pages invoke a function from the common JS file on page load.
Live demo:
http://www.ecmazing.com/misc/pause-execution/mainpage.html
http://www.ecmazing.com/misc/pause-execution/nestedpage.html
http://www.ecmazing.com/misc/pause-execution/common.js
The common JS file contains one global function which paints the H1 element red. I would like to pause execution at the beginning of that function, so that the execution is paused while the H1 element is still black.
How to do it on the main page:
This is trivial. Simply load the page, open the dev tools of the browser, select the common.js file, and set a break-point at the first line of the function. Now, reload the page. The break-point will persist the reload, and execution will be paused.
How to do it on the nested page:
Now, in Chrome and Firefox (Firebug), the break-point that was set above (for the main page), will also work for the nested page. Both pages use the same JS file, and setting a break point in that file will apply for both pages automatically. Unfortunately, this rule does not apply to IE.
And even worse, even if I set the break point subsequently, and then reload the iframe only , the break-point will not persist.
So, I don't know how to pause execution for the nested page in IE. Can it be done? (I'm dealing with this by manually setting a debugger; at the beginning of the function, but I would love to be able to set the break-point via the dev tools in IE, if that's possible.)
7 answers
solution1
4 ACCPTED 2012-05-25 11:53:33
The closest I can come to a solution is to set a breakpoint within the loadIFrame() function on the main page and then 'step in' until the nested page's Common.js file is loaded. In a more complicated example you would then be able to set your breakpoints within the new Common.js file and they would work correctly until the next time the iframe is loaded, when they would all be lost again.
solution2
3 2012-05-25 03:43:29
I don't have IE9 to test, but perhaps you can treat common.js file as a separate asset for the iframe page? I believe that's why it works in other browsers since those files must be tagged or labeled by the browser some how.
An example is to append ?iframePage to the end of common.js on the iframe page. At least in Firefox is shows an asset loaded as common.js?iframePage . Everything past the query string is ignored by the browser but otherwise the JavaScript is loaded with that exact name.
Another example is to make a copy of common.js and renamed it to commonClone.js which is then used for the iframe page.
Either example might allow you to set the break-point twice in IE9, one for each asset.
That said, there's nothing stopping you from creating iframe only breakpoints that are independent of common.js file that the parent page is using.. This method, let's call it parallel break-point , allows for asynchronous debugging of JavaScript since the iframe page and the parent page are processing JavaScript independently yet may be working in tandem.
Reference for this method is from official source MSDN Library: Using the F12 Developer Tools to Debug JavaScript Errors section Managing Breakpoints that shows how to perform breakpoints on multiple JavaScript files.
According to a recent forum post at the IE9 Developers Forum, the solution to prevent reloading of JavaScript files when used for debugging is to use the inline event handler instead of attachEvent as shown in this example:
replace (or comment it out)
$(document).onload(function(){ mycustomonload functions});
with
<body onload="mycustomonload functions">
solution3
1 2012-05-20 13:45:10
If you are doing this solely for compatibility testing then have you tried using IETab plugin for Chrome?
This emulates IE's rendering engine while allowing you to use the Chrome debugger.
If this isn't good enough then I think you've hit an impasse, IE dev tools just aren't sophisticated enough.
solution4
1 2012-05-24 07:39:37
Perhaps, if you could restructure your Html and JavaScript code, you could only reference common.js from the parent page and make both the main and the nested page use the same JavaScript function.
That way one break point would satisfy both scenarios.
solution5
1 2012-05-24 12:42:59
To debug iframes in IE, and be able to set and retain breakpoints, you could open the iframe address in its own ie tab/window. This is not possible/straightforward however if the iframe communicates with its parent.
solution6
1 2012-05-27 04:40:35
I hope you at least are using IE Debuggy Bar. Update your common.js file with this code
function func () {
if(typeof window.parent.debug !== "undefined"){
window.parent.debug();
}
document.getElementsByTagName( 'h1')[0].style.color = 'red';
}
function debug(){
var a = "break here";
}
set break point to var a = "break here"; after your main page loads. When you hit Load Iframe button js will stop on that line. Use call stack to navigate to previous javascript instruction (line) which should be in common.js file in nestedpage.html. Now set another break point where ever you'd like and hit continue in debugger, or use STEP feature
== UPDATE ===
BTW, to answer your question, why break point cannot be persisted in iframe, think this way. Each time you click on "Load IFrame" button, old instance of window object is disposed in memory and with it all break points and new is created with new common.js instance. Same would happen if you would call windows.open("http://......");
Also keep in mind even you have same file loaded in both window(s) , it is loaded in two different execution frames in browser. you can run two browser instances of same browser but they are not showing same page in window. Tho, there are things which are shared, like cookies but that is out of scope of this topic.
solution7
0 2012-05-26 12:48:38
您可以使用setTimeout（）暂停javascript进行特定时间...
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.