Develop Reference

Loading sourcemaps and debugging in Safari?

We ran into an error that only occurs on Safari browsers, so I dusted off my OSX partition on my Macbook and am trying to debug it but I can't find out how to see the original source code and set a breakpoint.
My main file is main.d7f60b0631c7822cabf3.bundle.js and the last line of the file is this, which points to the sourcemap file which does exist because I can type in the url and get it, and it works in firefox and chrome:
//# sourceMappingURL=main.d7f60b0631c7822cabf3.bundle.js.map
In Firefox I can go to the debugger tab in dev tools and under sources I see my original source file webpack:///src/app/app.component.ts and I can open it and set a breakpoint.
In Chrome dev tools I go to the 'Sources' tab and do the same thing navigating a tree to webpack:// - . - src - app - app.component.ts.
Is there a way to achieve the same thing in Safari? From memory since I"m writing this on Windows I can't see any files in the debug tab, just a list of breakpoints. In the resources tab I can see the bundle and an arrow that looks like I should be able to expand it, but clicking on that arrow does turn it from right to down like it is expanded but nothing is displayed. Other files like jquery do seem to have the original source under them when expanded...

I had the same question, and found the answer in another posting here:
How do I toggle source mapping in Safari 7?
(short version, in the debugger, command-click on whatever symbol you want to look at, and it should jump to the original source. For reference, I'm working with TypeScript compiled to JavaScript)
The author points to this documentation:
https://developer.apple.com/library/content/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/ResourcesandtheDOM/ResourcesandtheDOM.html#//apple_ref/doc/uid/TP40007874-CH3-SW4
In the process, I also noticed that in the Resources tab in the Safari debugger, it shows the foo.js with a turner next to it, which expands to show the original foo.ts file (and I assume with a more complex source, it might expand to show multiple sources if they get concatenated together?)
Personal opinion: I think the turner is a great solution to this problem... odd that the debugger defaults to showing the "compiled"/"transpiled" source rather than the stuff one is logically wanting to debug.

First be patient while the browser processes all the source maps.
Whenever that finishes, you should be able to search for any original source file by entering the name of that file into the input field located at the bottom of the pane with the placeholder "Filter". It's a pretty counterintuitive UX IMO. Hope this helps someone!
Screenshot:

breakpoint on javascript in CSHTML?

I have a .CSHTML file that has a javascript tag.
Within this script tag I have a few lines of javascript.
The first line of javascript refers to a property in the #ViewBag.
All other javascript lines are plain script without any MVC related references.
Observation:
I can place breakpoints (visual studio 2015) on each of these javascript lines.
However, all breakpoints has white dot in the center of the breakpoint symbol (red circle) EXCEPT for the line with the #ViewBag reference (this particular line does not have a white dot in the center).
It seems only the breakpoint without the white dot is hit during run-time.
Question:
Can somebody explain what is going on here?
What does the white dot mean?
Why is the plain red breakpoint line the only line that is hitting the breakpoint?

The Visual Studio debugger is actually expecting you to debug the actual server-side code within your .cshtml file as opposed to the client-side Javascript within it.
IIRC, Visual Studio will allow you to debug Javascript code as expected in Internet Explorer (and possibly Edge), but for other browsers you will likely want to use either a third-party tool or the Developer Tools (F12) within your browser.
An easy approach would be to take advantage of Javascript's debugger keyword, which you can place in your code and run with the Developer Tools open (just press F12 and then refresh your page). It will hit a breakpoint and the browser will allow you to step through your code as you might expect :
function doWork(){
// Ensure that this line is hit with the Developer Tools open in your
// browser
debugger;
// Do work here
}

Chrome Developer Tools keeps breaking where no breakpoints are set

When debugging JavaScript code using Chrome Developer Tools the debugger pauses on code where breakpoints are not set. I don't have the Pause on exceptions feature enabled, and there definitely are not breakpoints set (see attached image).
I asked a similar question before which was helpful but didn't quite solve this issue (previously I had the Pause on exceptions enabled). In the example below I swapped out the minified version of kendo.all.min.js for the unminified version, which allows me to see where the script execution is being paused, but I don't know why it is being paused. This happens a lot with jquery.min.js too.

I fixed my breakpoints problem by clicking the "Restore defaults and reload" button located in the “Settings” section. To find the button: In Developer Tools click the cogged wheel next to the top right three vertical dots. (Note: If using older versions of Google Chrome, click on the top right three vertical dots and then select “Settings F1”). The button “Restore defaults and reload” is at the bottom right.
Also note that it really restores defaults - you lose all previously saved breakpoints and any files you have open in Developer Tools will be closed.
I got this solution from: Chrome javascript debugger breakpoints don't do anything?

Accepted answer to Import/export Chrome devtools breakpoints & settings between computers reminded me to check "devtools-on-devtools" and in the DevTools' inner Application Local Storage remove the faulty element(s) of the JSON list value for key breakpoints to fix my same issue without resetting everything.
Later it happened again, so I wrote this console snippet:
((stores, matchKey, removeMatchingRegExp, dryRun)=>{for(let store of stores){
let r = JSON.parse(localStorage[store]), l = r.length;
r = r.filter(b=>!b[matchKey].match(removeMatchingRegExp));
if(!dryRun) localStorage[store] = JSON.stringify(r);
console.log(`${dryRun ? 'Would' : 'Did'} remove ${l - r.length} entries from ${store}:`, r)}; return 'OK'})
(['breakpoints', 'domBreakpoints'], 'url',
new RegExp('^https?://example.com/script.js$'), true)
Note:
Provided without warranty: Use at own risk. Backup your data.
Edit it - at least the RegExp argument - to suite your needs.
The last-most boolean should be false to disable dryRun.
Outer DevTools must be reopened for effect.

I was able to resolve this by updating Chrome. I don't think the version matters, just the process of updating resets all of the breakpoints that have been stored in the cache.

F8 has two functionalitys. 1. Skip ot next Breakpoint, 2.stop wherever the Browser is executing code. This works even if you have no breakpoint set. For example spamming F8 when you forgot to deactivate breakpoints might cause the browser to stop anywhere.
When you go to the debugger shortcuts you can see that F8 has the functionality to Pause / Continue. But it sadly seems like you can't split them on two different keybinds.
Since I know this feature I never ran into this "bug" anymore.

I'm posting this answer in case it will help someone who, like me, missed an important clue as to the cause of the phantom breakpoint behavior. In my case, it was "user error" --mine. The root cause was a forgotten "debugger;" statement in a JavaScript file that was itself generated from TypeScript. I had removed the debugger; statement from TypeScript locally, run and tested without issue from localhost. But I had pushed the version with the statement to remote and it built and released to our dev site with the statement present. The dev site build excludes the TypeScript source files. When the debugger statement was hit, Chrome tried to load the .ts source and displayed "Could not load content..." I just assumed it was at a breakpoint (I'd set many during testing). And when I saw "No breakpoint" I assumed Chrome was experiencing the issue addressed in this thread. If I'd bothered to look in the Call Stack trace, I would have seen the source code line in the .ts file and pretty quickly figured it out. Here's a screenshot:

just disable the cache and reload the page, the breakpoints will show up again

Easier way of testing and adding Javascript to a page in Firefox?

I am trying to extend some Javascript in one of my pages and for quick "will this work" code it's a huge pain. Basically it consists of editing code in my IDE and save, switch to Firefox, reload page, set breakpoint in Firebug, examine and repeat
Are there any Firefox extensions that will aid me in this respect?
The only thing I can find is using javascript: ... in the address bar, but that's a huge pain, can only hold a single line, and there is no way of making the test code persist across a page reload.

Try jsfiddle.net. You can experiment with html, css and code within your browser and debug that with firebug for example. You can use a diversity of js-frameworks (or none), simulate XHR, and add your own (js/css)resources. It's not ideal, but much better than the practice you described.
You can also try using KomodoEdit, which offers 'view in browser' functionality, even for URLS and with a preset browser.

just use the js console that comes with firebug. You can write all manner of code in there and even declare functions and variables that can be referenced. if you need more than one line, firebug can do that too.
EDIT: except page reload.... if you need to do page reload it needs to be saved somewhere. I would use a Greasemonkey script

You can use the Web Console (new in Firefox 4 and higher) - press Ctrl-Shift-K to open it for a particular page. The command line is at the bottom, press Shift-Enter on the command line to enter more than one line.

My javascript file is displayed as a single line of text in the chrome debugger. Why?

I seem to run into this randomly. It usually displays the file normally, but sometimes it's all scrunched onto one line. I can't figure out what's causing it.

N.B.: In the current version of Chrome, this is actually done by clicking on the {} icon ("pretty print") on the lower left of the developer tools pane.

Ah, figured it out. The line endings on the problem file got set to Mac format somehow, while the rest of the files were Windows format. Not sure how the format swapped but it's easy to convert back (in Notepad++ just go Edit -> EOL Conversion).

You already answered your own question, but this is a good place to note that Chrome (as of v12, currently in dev channel) has a built-in pretty-print function that can make quick work of the typical one-line JavaScript files that all well-behaved websites generate. In Web Inspector's Scripts tab, select a file via the usual dropdown, and right click on the source code. Selecting "De-obsfucate Source" will format the file in a reasonable way, and even allow you to set breakpoints inside the newly reformated code. It's quite helpful.