I am attempting to debug a page issue where IE 9 will work the first time on my requirejs/backbone application, but will fail on the page reload. However, when I attempt to debug this problem using the f12 IE developer tools, I cannot navigate to the source to set a breakpoint because IE does not load any of the files that RequireJS includes. How can I get around this issue to fix my IE headache??
I guess I am late for the party but hope my answer helps you and others as well.
The file that you want to debug or the line in the file, simply add this --> debugger;
before that line.
So, when require.js loads your script and encounter that string i.e. debugger; exists it will automatically be stopped at that line.
You can generate a single js File with require tools :
include requirejs in this single file
(http://requirejs.org/docs/optimization.html#onejs)
set optimise to
none (no source minified -
http://requirejs.org/docs/optimization.html#shallow)
In your index.html link this file instead of require.js.
You can debug with IE.
I have the same problem from time to time. What sometimes helps: Close all the files in Debugger view, leave the DevTools open, press Play to allow page to continue and then make your action on the page or reload - if it halts on the debugger; again, all the files will be loaded. But still investigating ;)
Related
I have a migrated SharePoint application that brought over a bunch of old JavaScript files. One of these files is causing errors in the new environment but I'm unsure of the culprit. They aren't throwing console errors, but rather modifying elements by adding unwanted attributes and classes
Is there a way to prevent the loading of individual .js files without modifying the source? I know blackboxing will prevent the debugger from stepping into the code, but it still loads. If I can narrow it down to one file, I can fix the conflicts that are occurring
Another solution is using Fiddler (http://www.telerik.com/fiddler). It allows you to isolate particular js files and either force them not load, or it allows you to inject your own local JavaScript files on the fly. This way you don't have to migrate your project/solution locally for testing, you can continue to run this on your sharepoint server, and use your own local JS files..
Good luck!!
For the record, this can now be done directly in Chrome Devtools as of version 59.
Load the page, open devtools, then click the network tab. Find the request you'd like to block, right click on it, then select "Block request URL" & reload the page. That resource will be blocked this time around.
Very useful!
Ok, posting this as an answer:
Although intended for other uses, AdBlock Plus can do what you're asking, and it's available for all major browsers.
Just set up a filter like example.com/path/to/your.js and that script should no longer get loaded.
Although I used pretty code and had set up the breakpoints in "Pretty code" tab, debugger keeps working in minified code. (I can't see exactly where I am and need to continuously switch between source and "pretty code").
On same pages with same script it sometimes work and sometimes don't. I can't find the cause or any difference in the way I activate it.
Is there any way to force debugger to use "pretty code"? Any Ideas or additional questions? Should this be reported as a bug?
EDIT: I still don't understand what is going on but there is a fix for it. So when this situation happens, just edit script and add "debugger;" keyword after the cursor. It will make a breakpoint. Then, if you use "pretty code", debugger will stay inside prettified code. As I said, I don't understand why is this happening so I'm still waiting for answer(s).
EDIT: Current browser version is 42.0.2311.135 (64-bit).
EDIT: Dave pointed out that there is a reported bug on something very similar. https://code.google.com/p/chromium/issues/detail?id=415406 It says it's related to file size but I can't confirm this. I changed title to reflect these findings.
In Chrome and Safari, simply select the 'Scripts' tab, find the relevant file and then press the "{ }" (pretty print) icon located in the bottom panel.
You can call this a bug. You can call it a dillema.
Open ticket from Aug 9, 2013
(Chrome v. 28)
Bug Reporter's observations
I've been spending some time debugging this, and familiarizing myself
with how to develop devtools locally; I'm not sure if all of this is
helpful, but here's a braindump of what I've looked at so far and some
hunches:
When attaching a breakpoint in the original .js file, the UI seems to
get confused and assigns the breakpoint to the associated .coffee or
.ts file per the sourceMap association [see image-1, attached]
However, when unchecking the breakpoint to disable, the UI correctly
updates to show the breakpoint in the right place in the .js file.
[see image-2, attached]
It seems to me there is either an incorrect lookup happening in
WebInspector.CompilerScriptMapping.rawLocationToUILocation or
WebInspector.CompilerScriptMapping.uiLocationToRawLocation
Open ticket from Sep 21, 2014
(Chrome v. 37)
Chromium Developer's Observation
This is not something that could be solved easily. The breakpoint
manager is build around the idea that the breakpoint is always shown
in the "best possible" UI location, which is uncompiled source in case
of source maps. Fixing this would require us to use breakpoint's
primary ui location as a hint to where it should be shown. Moreover
since execution line will be shown in the uncompiled sources by
default, it is essential that we keep showing our breakpoints in them
as well. So this all ends up in the need to show breakpoints (and
execution line) on several ui locations at the same time. All actions
with these locations should work smoothly etc.
This is a significant effort and does not sound like a "GoodFirstBug"
to me.
Conclusion:
Prettify does not seem to create a new non-minified version. Rather it is rendered. This makes sense. With all the different frameworks and flavors (e.g. Coffee), if the debugger created a new file, there is high potential for error.
The breakpoint
manager is build around the idea that the breakpoint is always shown
in the "best possible" UI location, which is uncompiled source in case
of source maps.
I interpret this to mean the Chrome browser and debugger will continue running from the minified version. When you set a break-point in a "pretty" file, the debugger sets it in the minified file and gives the developer a "pretty" rendering of debugger stepping through minified file.
This is a lot for the debugger to manage, and can be rather fragile. We can call this a bug or a very ambitious feature for which many things can go wrong.
**
I have added this thread to both bugs and emailed both developers assigned to it.
**
As of 2020, similar behavior still occurs in a specific situation:
You open a source-mapped document, i.e. it shows "(source mapped from ...)" on the bottom of the window
You prettify it
You place a breakpoint in the prettified version
The debugger will stop in the ugly source-mapped file
The solution seems to be to go to the original source from which you mapped, prettify that, and place the breakpoint there.
Chrome 79.0.3945.88 ; Webpack 4.41.2
Seems like you are clicking the "{ }" (pretty print) icon located in the bottom panel and setting a breakpoints there without attaching a source map of the original file.
When given a .map file, Chrome dev tools and map each line of executed minified code to the original source file using the data in the .map file. Otherwise it will just do it's best to indent/format the minified file.
I suggest you use grunt uglify or similar to minify your js which will automatically generate a map file for debugging. See the following links for more information on how to do this.
http://blog.teamtreehouse.com/introduction-source-maps
Javascript .map files - javascript source maps
How about this?:
Generate the pretty-print version of your "min" version and save using your "min" version name: Substitute the "min" for a pretty "one"
simply put debugger; at top of the js code.
ex:
function add(n1, n2) {
debugger;
let sum = n1 + n2;
return sum;
}
To debug a third-party npm library during local development.
Update package.json from "node_modules[package_name]\package.json"
"main": "dist/package-minified.js" -> "main": "dist/package-formatted.js"
Rebuild your project
You will be able to set a breakpoint to the third-party js library.
Usually, libraries come with both formatted and minified js files. You will find them under node_modules[package_name]
dist/[package-name]-src.js
dist/[package-name]-min.js
I'm very new to JavaScript, jQuery, and JSON browser debugging. But I do know that the "Sources” tab in chrome dev tools is supposed to let me look at my JavaScript files in the browser so I can set and manage my breakpoints and effectively debug my code.
However, when i press Ctrl + Shift + I to open chrome dev tools, i can't see a list of my javascript files under the Sources tab.
I only something in the form of...
jslib.axd?=jquery-.7.2.min.js,query.validate.min.js,MyRegion.js,MyCountry.js,MyCategory.js
...which looks like a concatenated list of all my javascript files. But what i was expecting to see is a list of each of my javascript files.
Screenshot:
It looks like you have used a compression tool to combine all of your javascript files. What you see is not an error in Chrome - it's just all of your script files combined into one.
If you are still developing, just turn off whatever tool you are using to compress them (at least until you are finished your dev work). This will allow your scripts to load individually on the page.
Then you can use chrome dev tools to see each file listed.
If you want to set a break point. Use 'debugger' in your code like so :
//code here
debugger;
I never use Chrome to debug javascript but i'm sure you can do it easilly. Firebug in firefox is great and you can also debug in Visual studio if you use IE with 'debugger'.
Hope this help.
If you use chrome/firefox just press f12 it will open web development tool
now go to source/script section and select the js file in which you want to add a break point
just click on that line to add break point not run the function it will come to your break point and then you can debug through F10 for singe line and move for next break point press F8
I have a web page which includes insane amount of minified JS files. The web page works perfectly fine on my local network but throws some JS error on staging. There is an issue in JS and I wan't to debug it. When I load the JS in Firebug's script tag it appears in one long horizontal line. Is there a way out in Firebug that expands or beautifies the script for debugging? I know I can use jsbeautifier but they wont help me. I can not upload an expanded file to CDN, defeats the purpose of using CDN.
Points to be noted,
a) I can not control the box which serves JS, its on CDN, I mentioned it.
b) I can use beautifiers etc but would that help me in debugging the script in run time? IMHO, no
c) Being bound by NDA and other legal things I can not share the script but its a generic problem, you can encounter it with a minified jQuery
Beautify your script
Add the CDN host in /etc/hosts or your local DNS to resolve it to your own web server
Host the beautified version and everything that you need on said web server
Both Firefox and Chrome (versions as of this edit) support beautifying script with the {} button available in the inspector.
Just load the minified file and press the {} button at the bottom and it instantly beautifies, making breakpoints and other debugging possible. (True for Chrome too)
This is a common problem and the Chrome dev team have recently come up with an elegant solution, which they've called Source Maps - see http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ for more info, I think you'll find it's exactly what you (and the rest of us) have been crying out for! :)
This is more a workaround, but it can help. The idea is that we will replace files coming from the server by files on your machine.
This will work with any browser.
It takes a bit of setup the first time (15 minutes maybe), but then it can be very convenient.
It can also helps testing your bug-fixes in a live/prod environment.
Get Fiddler (it's a web debugging proxy), install it, run it.
http://www.fiddler2.com/fiddler2/
(Restart browser after install to get the Fiddler extension)
If you debug an HTTPS website, check this first:
http://www.fiddler2.com/Fiddler/help/httpsdecryption.asp
From now on, you should see in Fiddler ("Web Sessions" pane on the left) all downloads made by your browser, including JS files.
If not, check this : Fiddler not displaying sessions
Find the file you want to debug in the list (Ctrl+F works)
Click on the file. Then either:
get the file content from the inspectors pane (textView tab), beautify it, save to a file on your local computer
or have access to a file which contains the source code (ex: from your source control)
Go to AutoResponder tab (top left pane).
Select "Enable automatic responses" checkbox.
Select "Unmatched requests passthrough" checkbox.
Drag your file from left pane to right pane (prefills rule editor at the bottom)
Set the other field with the path of your local file
Click the Save button
Reload the page and enjoy your debugging session.
Fiddler can do many more things, but this use-case answers the initial question.
Consider a Change!
Firefox w/ Firebug was my favorite JavaScript debugging method for almost a year, but I've recently moved to Google-Chrome's Developer-Tools which is far more superior.
Chrome supports an On-The-Fly (built-in feature) beautification of JavaScript resources
Once beautified, you are free to debug the JavaScript resource file, as it was "natively" downloaded beautified from the web-server. Breaking-points are set by clicking the line number.
One of the most extremely powerful feature,
Is once You've Stopped In A Breaking-point, You Are Free To Execute Commands (using console) In The Same Scope You ARE In The Breaking-point. In Firefox you can't do that.
Its so easy to debug (even anonymous functions), You'll never be back to Firefox.
Try It!
Pretty-print your JavaScript. Google this and you'll find multiple on-line JS beautifiers.
I happen to use http://jsbeautifier.org/ myself and it works fine, but search for others and use one that suits your needs.
Caveat: You still won't be able to get meaningful local variable names (which are usually renamed by a minifier). If the code was compiled by the Closure Compiler, then you absoutely won't get any useful information back at all, even when beutified, because then all variables and functions and properties are mangled (not only local ones).
Now, if your problem is with debugging code that comes from outside (e.g. a CDN), obviously that code would be minified, and you can't save your beautified version back there. In this case, you can replace the tags that load code from a CDN with a url pointing to your local version, then you can beautify the code (downloaded from the CDN) into your own server and you can then debug with FireBug.
Now, if you don't even control the HTML that contains those tags (e.g. they reside on a outside server), then unfortunately there is no way for you to do what you want without physically downloading the entire site to your own server. Even if you downloaded the entire site (with all the files), it may not work since the site may be driven by a back-end processing language or accesses a back-end database. In such case you'll also need to simulate all those data. It can be done, however -- you just have to go through a lot of pain. My recommendation is to save a version of the web page and run it on your own server, serving beautified code from your own server to debug.
Placing breakpoints on JavaScript makes debugging much easier, but if your code has already made it to production then it's probably been minified. How can you debug minified code? Helpfully, some of the browsers have an option to un-minify your JavaScript.
In Chrome and Safari, simply select the 'Scripts' tab, find the relevant file and then press the "{ }" (pretty print) icon located in the bottom panel.
In Internet Explorer, click the tool icon by the script selection drop down to find the option to format the JavaScript.
Opera will automatically prettify minified JavaScript. Source
I just installed VS 2010 Beta 2 and wanted to play with an ASP.NET MVC 2 project. I simply added some script (alert('hello');) into the Home controller's index.aspx view, and I can see it executing. When I try to set a breakpoint, however, it never gets hit. I also tried to use the "debugger" keyword, and when I do, I get a disappointing "there is no source code available for the current location" message. I also get this message when I try to independently attach to an IE process where my app is running.
What do I need to do to get a friendly script debugging experience? (I have successfully used Firebug to debug this, but for some reason I prefer the VS debugger.)
Here are some details of my configuration:
I am launching my stuff in VS 2010 Beta 2.
IE8 version 8.0.7600.16385 is my default browser.
The "Disable script debugging (Internet Explorer)" advanced option is unchecked.
The "Disable script debugging (Other)" option is unchecked.
In my ASP.NET MVC 2 project's "web" properties tab, the ASP.NET debugger is checked. All others are unchecked.
Visual Studio 2008 script debugging seems to work just fine.
The debugger cannot debug both Silverlight code and Script code at the same time, if the Silverlight debugger is selected JavaScript debugging is switched off.
Go to the Project's Properties (Alt+Enter).
For a Web Site Project: Select "Start Options". Or for a Web Appliction: Go to the Web tab and at the bottom you will see the Debuggers option.
Check that the Silverlight checkbox is NOT ticked if you want to be able to debug JavaScript. (It is unfortunate that the UI here is not clear about this side effect.)
I was having the same issues. I was not able to get the IDE to even break at a breakpoint set inside a script tag. However when I added "debugger;" as the first line in the script tag was able to get the IDE to respond but then only to say that the disassebly was not availble.
However, I was able to click on the debug tools like "step into" and "step over". When I did this the IDE did progress into some of the external scripts that I am using (JQuery and Google Maps). So I took the JavaScript code block out of the view and put it into a separate .js file in the "Content" folder. Then I added a script tag to reference this new .js file (url = "/Content/Test.js").
It worked... a little bothersome that you have to go through this effort but maybe there is something to be said for JavaScript not being included directly in a view. I hope this is a bug they intend to fix.
When debugging on IE, VS seems to add a folder called 'Script Documents' to the Solution Explorer. Inside this folder there is another folder called 'Windows Internet Explorer', and inside of it I see all the loaded js scripts and the (compiled) HTML file currently being displayed on IE. Setting breakpoints on the script tags in this HTML file does work for me.
To resolve this go to the Project's Properties and select "Start Options". Then Check the Native Code Check Box. and Uncheck the Silverlight Checkbox because both options not works together.
CTRL+Alt+P (Attach to Process), select IE, select 'script' for the debugging type.
As Ryan noted above, I moved my script to a seperate file under the Scripts folder.
I also added debug into the name of the script so it became MyTestScript.debug.js. I included the script via a script tag and could set break points in the script file which the debugger hit.
I have found that the Google Chrome devloper tool shows the JavaScript perfectly. In my case, I'm normally loading the script with jQuery's getScript function and execution of the code is typically by way of a jQuery callback upon loading a page or handling an event. With Visual Studio 2010, I frequently encountered the "No source" bug. Sad I need Chrome to debug JavaScript that is part of my Visual Studio project.
Using a separate js file has its drawbacks. For instance, you can't use MVC helpers. Microsoft really needs to figure this one out.
Intellisense also does not work properly in script blocks on a view, even if you include the reference comments like this:
/// <reference path="/Scripts/jquery-1.6-vsdoc.js" />
/// <reference path="/Scripts/jquery-1.6.js" />
Intellisense works fine in the js file with this approach though.