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
Related
What have I done?
I'm running a ASP.net / Polymer website in VS2010 Development server.
It all used to run fine I could set a breakpoint in some JavaScript, run the site in Debug mode and it would break at the set location.
I obviously changed something though because now I can only set a breakpoint once the Javascript is loaded or by putting a debugger; statement in the code
Actually, I can set a breakpoint (or appear to) but it doesn't break at that location
Just me being stupid again
It turns out the problem was because I had added the folder containing the Javascript source to the workspace (by right clicking in the Sources pane)
Having done this the folder tree which used to appear under the localhost:nnnnn parent in the Sources pane no longer showed
Don't remember adding them but obviously I did
Removing the folders fixed it
I mainly put this answer here so that the next time I do the same thing and look it up on Stack Exchange I will find the answer
I have found the best way to add a breakpoint with Chrome is just adding this in the code:
debugger;
So long as the code is actually run and you have the javascript console open it will be caught.
But sometimes the I have found the dev tools get broken and require the entire browser to be restarted.
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'm trying to debug an AngularJS app in Chrome (with the Jetbrains extension) within Webstorm 8. It's working just fine, but the only naggy thing is that the actual file that has breakpoints in it doesn't get debugged, but a readonly copy that reads as the full url of the file is (see screenshot). It works, but I cannot edit the readonly file while moving from line to line.
edit: plus, the IDE usually shows an outdated version of my JS file and I have to manually refresh it to see the correct one.
The Webstorm Run/Debug config for Javascript is really straight forward, basically just the URL to the app.
Does anyone knows how to avoid this?
Cheers
The short answer is: you can't
The longer answer is, the computer is not running the code that you see on the screen, that's just what the debugger is showing you. The computer is actually running optimized, non-human-readable Javascript bytecode, which is created when you start your JS program, after syntax is checked, namespaces are created and memory is allocated for variables etc. You can't edit that bytecode by writing JS code directly, at least not with any debugger I know of (and I'm fairly certain you can't with Webstorm specifically; I use PHPStorm and its Javascript debugger).
Such problems usually mean that remote files are not correctly mapped to local ('remote URL' not correctly set for local files in Run configuration), so the debugger can't map the files being executed to your actual sources. I'm not sure what your application looks like... But, as Angular apps structure is more or less standard, I can suggest mapping the 'app' folder to 'http://localhost:9000' in javascript debug run configuration you are using to debug your angular code
I'm developing a Symfony2 application using PHPStorm IDE.
I can't seem to make it work. I've tried Javascript Debug for both local and remote with multiple parameters. Messages varies from "Remote URL isn't specified for so breakpoint..." etc.
Best case scenario is that I would be able to debug my Javascript codes inside PHPStorm. Is this possible?
I'm also using AsseticBundle for my assets.
I use PHPStorm too but I only use it for coding, debuging is in browser..
So I would say it depends on if PHPStorm executes the app_dev.php and graps the output.
If you already have experience with PHPStorm (Debuging) you could answer this. I myself don't think so...
Hope I could help at least a little :)
JavaScript debugging is definitely possible from the PhpStorm if you are using Chrome or Firefox browser. Debugging JavaScript and PHP at the same time is not supported at the moment.
I was able to set this up
Install the JetBrains Chrome extension
In PHPStorm click the Run/Debug Configurations just to the left of the green bug near the top right
Add a Javascript Debug (using the plus sign)
In the URL box, just enter the URL of the page you're debugging (e.g. http://my.test/app_dev.php/route/here/not-there/3290), name the config, and apply
Add breakpoints in the js
Make sure dev tools is closed in the browser, then click the green bug (ensuring that the config named in 4 is chosen) and it will redirect to the page specified in 4.
The breakpoints will now be activated and are able to be stepped through (like xdebug). When it stops on a breakpoint it may be in a version of the original file with the file's name appended with a version number (this file is read-only). There is a button to the left hand side of the name where you can reload the read-only file being stopped at, after you have updated the actual (writable) file.
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