Debugging for MS Edge constant reload - how to trigger debugger? - javascript

I am debugging some code on the MS Edge browser, but it reloaded twice and showed a "This page is having a problem loading" message after two tries. The page has been tested on IE11 or lower, Chrome, and Firefox with no issues.
I have been having trouble bringing up the debugger during page execution by placing the debugger statement in various parts of the code. I have placed it in the first line of the script in the body tag, I have placed it in the first line of $(document).ready(); and even in the script tag in the header. I am so surprised when none of the debuggers triggered other than the one in IE11 (both Chrome and Firefox did not trigger either). Edge of course still continued on its reload loop and saying that it has a problem loading.
My question is - am I not doing this right? Is there a list of when a debugger; statement will not trigger? And more importantly, how do I trigger it in Edge before it reloads twice and throw the error page (For reference, pulling up F12 after it throws the error page gives the DOM of the error page, which is not helpful.)

This is an issue with Edge where the console seems to crash along with the browser. I have noticed it numerous times during development and have not been able to find a solution.
Check in every other browser on an empty cache and see if you are getting any errors in console. Older versions of Edge, before the last service pack were very flakey so I would suggest making sure your environment is upto date.

Related

How to debug StealJS with IE 11 and Firefox 36?

I use the minor tag of StealJS to load my JS files and everything seems to work, but today I recognized that I'm simply unable to debug my code in IE 11 and Firefox 36. Until now I only used the new Opera based on Chrome/Blink, currently version 27, which works pretty well regarding debugging. But:
Firefox's built in dev tools don't show my JS files at all. They only show steal.js and directly afterwards a greyed out line called "evals" with two additionals lines of two JS libs I use and export in stealconfig.js.
Firefox's Firebug shows my files and I can set breakpoints, but there seems to be some errors, because if I set/unset the breakpoint there's a little animation shown which never finishes. If I reload the page the usual breakpoint icon, a red circle, is shown, so it looks like the breakpoint has been set successfully, but the code simply doesn't stop on the breakpoint. But it is run, because the functionality implemented at the break point is usable.
In IE 11 my JS files are shown in the "dynamic scripts" tree and I can set breakpoints as well, but everytime I reload the current page the icon for the breakpoint changes and gets some defect triangle with a warning sign, just like the breakpoint won't work anymore or such. And of course IE doesn't stop the code as well after I reload the page and if I open my JS file the breakpoint is not shown anymore, which at least works in Firefox's Firebug.
None of those problems happen in Opera/Chrome, I always see all my files, can set breakpoints and the code stops as expected. Additionally all browsers show individual requests for my JS file, nothing is bundled into one big one or such, it's all independent files during development.
So is StealJS and how it loads files simply incompatible with the other browsers? Do they need to add support for how Steal handles file loading? I used a former version of Steal with JavaScriptMVC and none of these problems occured with that version.
Looks like those are browser issues, so go and write bug reports.
https://github.com/stealjs/steal/issues/419#issuecomment-99059303

How to debug infinite loops in Firefox/Firebug?

I have an issue with Firebug in Firefox. While my JavaScript produces an endless loop, a popup in Firefox comes up, which allows to continue the script or terminate it.
In earlier versions of Firefox there was an additional option allowing to debug the script, however it is not appearing anymore in the popup in current versions (I am using Firefox 31.0).
Using this option Firebug should stop somewhere in the JavaScript processed in the endless loop. Most likely this behavior can be again activated in Firebug/Firefox but I do not know where?
While this button is not present in Firefox 31.0, it is there in version 32.0. Though instead of stopping in Firebug it now uses the built-in debugger to debug the script.
Background info:
Before version 2.0 Firebug used Firefox' old debugger API called JSD. In Firefox up to version 31.0 the Debug script button is just displayed when that API is enabled, i.e. when Firebug (1.12.* and earlier) is opened for that page.
The debugger of the built-in devtools and Firebug 2.0 use a new debugger API, so as the button is bound to JSD it is not displayed.
In Firefox 32.0+ the button works together with the new API. Though as Firebug (2.0.*) doesn't hook into the logic for that button, it opens the built-in debugger.
There is currently no way to stop the script execution on hanging scripts. There used to be a button to debug them, though it got removed in Firefox 45.
The enhancement request to re-add it is https://bugzil.la/1157820.
For what it's worth, here's a simple test script creating an infinite loop:
data:text/html,<script>while(true){x=1;}</script>
Edit:
There is still a Debug Script button in the Firefox Developer Edition, though it doesn't seem to work (at least in the tested version 81.0b9) trying it with the simple script above.

How to terminate script execution when debugging in Google Chrome?

When stepping through JavaScript code in Google Chrome debugger, how do I terminate script execution if I do not want to continue? The only way I found is closing the browser window.
Pressing "Reload this page" runs the rest of the code and even submits forms as if pressing F8 "Continue".
UPDATE:
When pressing F5 (Refresh) while a script is paused:
Google Chrome (v22) runs the script. If the script submits HTTP request, the HTTP response for that request is displayed. The original page is not refreshed.
IE 9 just freezes. However IE has an option "Stop Debugging" which, when pressed (provided you did not press F5 earlier), continues to run the script outside debugger.
Firebug behaves identically to Chrome.
Closing and then opening again the browser window is not always the next easiest way
because it will kill browser session state and that may be important. All your breakpoints are also lost.
UPDATE (Jan 2014):
Refresh while debugging:
Chrome v31: lets scripts to run and stops on further breakpoints (but does not submit ajax requests), then refreshes.
IE 11: refresh does nothing, but you can press F5 to continue.
Firefox v26: lets scripts to run but does not stop on further breakpoints, submits ajax requests, then refreshes.
Kind of progress!
Navigate to the same page while debugging:
Chrome v31: same as Refresh.
IE 11: scripts are terminated, new browser session is started (same as closing and opening again).
Firefox v26: nothing happens.
Also juacala suggested an effective workaround. For example, if you are using jQuery, running delete $ from console will stop execution once any jQuery method is encountered. I have tested it in all above browsers and can confirm it is working.
UPDATE (Mar 2015):
Finally, after over 2 years and almost 10K views, the right answer was given by Alexander K. Google Chrome has its own Task Manager which can kill a tab process without closing the tab itself, keeping all the breakpoints and other stuff intact.
I even went as far as BrowserStack.com to test it in Chrome v22 and found that this was working this way even at that time.
Juacala's workaround is still useful when debugging in IE or Firefox.
UPDATE (Jan 2019):
Chrome Dev Tools at last added a proper way to stop script execution which is nice (although a bit hidden). Refer to James Gentes's answer for details.
In Chrome, there is "Task Manager", accessible via Shift+ESC or through
Menu → More Tools → Task Manager
You can select your page task and end it by pressing "End Process" button.
As of April 2018, you can stop infinite loops in Chrome:
Open the Sources panel in Developer Tools (Ctrl+Shift+I**).
Click the Pause button to Pause script execution.
Also note the shortcut keys: F8 and Ctrl+\
2020 April update
As of Chrome 80, none of the current answers work. There is no visible "Pause" button - you need to long-click the "Play" button to access the Stop icon:
One way you can do it is pause the script, look at what code follows where you are currently stopped, e.g.:
var something = somethingElse.blah;
In the console, do the following:
delete somethingElse;
Then play the script: it will cause a fatal error when it tries to access somethingElse, and the script will die. Voila, you've terminated the script.
EDIT: Originally, I deleted a variable. That's not good enough. You have to delete a function or an object of which JavaScript attempts to access a property.
[2022 edit: this was reported as https://bugs.chromium.org/p/chromium/issues/detail?id=774852 and https://bugs.chromium.org/p/chromium/issues/detail?id=1112863 in 2017, and was just recently marked as fixed 5 years later, so if you are still experiencing this, you should update Chrome (and in general keep it updated). If you are experiencing this issue in 2023 or forward, it may be a different issue, a bug regression, etc.]
If you are encountering this while using the debugger statement,
debugger;
... then I think the page will continue running forever until the js runtime yields, or the next break. Assuming you're in break-on-error mode (the pause-icon toggle), you can ensure a break happens by instead doing something like:
debugger;throw 1;
or maybe call a non-existent function:
debugger;z();
(Of course this doesn't help if you are trying to step through functions, though perhaps you could dynamically add in a throw 1 or z() or somesuch in the Sources panel, ctrl-S to save, and then ctrl-R to refresh... this may however skip one breakpoint, but may work if you're in a loop.)
If you are doing a loop and expect to trigger the debugger statement again, you could just type throw 1 instead.
throw 1;
Then when you hit ctrl-R, the next throw will be hit, and the page will refresh.
(tested with Chrome v38, circa Apr 2017)
Refering to the answer given by #scottndecker to the following question, chrome now provides a 'disable JavaScript' option under Developer Tools:
Vertical ... in upper right (in Developer Tools menu, not in Chrome main menu)
Settings (in newer Chrome versions it is visible separately as a cogwheel besides the ... button, not under it)
And under 'Preferences' go to the 'Debugger' section at the very bottom and select 'Disable JavaScript'
Good thing is you can stop and rerun again just by checking/unchecking it.
Good question here. I think you cannot terminate the script execution. Although I have never looked for it, I have been using the chrome debugger for quite a long time at work. I usually set breakpoints in my javascript code and then I debug the portion of code I'm interested in. When I finish debugging that code, I usually just run the rest of the program or refresh the browser.
If you want to prevent the rest of the script from being executed (e.g. due to AJAX calls that are going to be made) the only thing you can do is to remove that code in the console on-the-fly, thus preventing those calls from being executed, then you could execute the remaining code without problems.
I hope this helps!
P.S: I tried to find out an option for terminating the execution in some tutorials / guides like the following ones, but couldn't find it. As I said before, probably there is no such option.
http://www.codeproject.com/Articles/273129/Beginner-Guide-to-Page-and-Script-Debugging-with-C
http://www.nsbasic.com/app/tutorials/TT10.htm
You can pause on any XHR pattern which I find very useful during debugging these kind of scenarios.
For example I have given breakpoint on an URL pattern containing "/"
If you have a rogue loop, pause the code in Google Chrome debugger (the small "||" button while in Sources tab).
Switch back to Chrome itself, open "Task Manager" (Shift+ESC), select your tab, click the "End Process" button.
You will get the Aww Snap message and then you can reload (F5).
As others have noted, reloading the page at the point of pausing is the same as restarting the rogue loop and can cause nasty lockups if the debugger also then locks (in some cases leading to restarting chrome or even the PC). The debugger needs a "Stop" button. Nb: The accepted answer is out of date in that some aspects of it are now apparently wrong. If you vote me down, pls explain :).
Go to the Sources tab and select Filesystem subTab
Select a folder, containing the file you execute
Accept folder access recuest
Select the file you execute
Put a breakpoint inside the file you execute
Click the "Pause script execution option"
Select the copy link address option in the RMB context menu
Paste the copied address into the browser address bar to open the file
File execution will be stopped at the breakpoint
Open the source tab in 'Developer Tools', click on a line number in a script that is running, this will create a breakpoint and the debugger will break there.
There are many appropiate solution to this problem as mentioned above in this post, but i have found a small hack that can be inserrted in the script or pasted in the Chromes console (debugger) to achieve it:
jQuery(window).keydown(function(e) { if (e.keyCode == 123) debugger; });
This will cause execution to be paused when you hit F12.

How to prevent double-refresh on frameset

I have a situation where pressing F5 or CTRL+R causes a frameset to load a frame twice. It happens on localhost, but as I've just put together an example for this question and uploaded it, I notice it varies by browser.
Visiting the link for the first time or clicking the browser address bar and hitting enter performs a 'normal refresh', as desired.
The test case I put together below has 2 frames, one left empty. When frame1.html loads, the frameset then sets frame2's src, which then loads frame2.html. Both should alert only once, but you'll see that is not the case for 'frame2.html'.
Behaviour-by-browser:
Chrome16 & Safari5.1 works as expected both localhost/live
FF9 double-up on localhost, works as expected live
IE9 double-up on both localhost/live
haven't tested other / older browsers yet, but I anticipate some agony
I tried clearing the src attribute on the frameset's unload event in the hope it might at least load nothing before doing the double-up and then loading frame2.html, but even if that had worked (which it didn't) it's nasty.
My questions:
Why is the double refresh happening, when it does happen?
Is there a way to prevent the double-up?
Here's the link: http://codefinger.co.nz/public/frameset_test/frameset.html and also the rar'd files: http://codefinger.co.nz/public/frameset_test/frameset_test.rar
Ok, lack of an explanation drove me mad, but I did find a way to stop this default, inconsistent behaviour.
I listen to the frameset's window.unload event (YUI3.5), and remove the double-up frame node altogether. The double-up goes away, everything appears normal.
Tested successfully in (both localhost and live server):
Chrome 16.0.912
Firefox 3.6, 9.0.1
IE 6,7,8 & 9
Safari 5.1
Does not work in:
Opera 11.61 (I can't access and manipulate the frameset element)
I'll still +1 for any explanations as to why the frameset load double-up occurs in the first place.

How do I overcome IE8 getting "stuck" in SCORM 4th Edition Compliance Test SX-05?

I am posting this in the off chance there is a SCORM expert out there that may have seen something similar.
Internet Explorer 8 gets "stuck" on step 14 of test case SX-05. Something doesn't trigger the continue. No amount of debugging and tracing reveals anything. It's as if the test case is "overwhelming" IE8's slow JavaScript engine. All other tests run fine in IE8. This one is quite complex, but there are others of similar complexity.
Install Chrome. No one can fix IE
Have you tried pausing the test before you get to SX-05, closing the browser and then resuming the test? That might help.
Are you sure it is an IE issue? We have successfully run the 4th Ed test suite many times without issue. If the test always stops at the exact same place, it seems unlikely that it is a resource issue. At what point does the execution stop?
This turned out to be rather obscure. Our LMS was writing a loading page to the content iframe before loading the actual SCO.
window.frames.contentFrame.document.open();
window.frames.contentFrame.document.write(html);
window.frames.contentFrame.document.close();
I changed the loading page to a static HTML page and everything chugged along fine. Modifying the document that way screws up some window events on Firefox and IE.

Categories