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:
Related
I know there is a ton of "similar" questions, but being similar doesn't mean they are the same, if they were the same, they wouldn't exist, I haven't found the answer I'm looking for.
It must be something simple, as in other projects of mine it does work.
There is a difference in behavior:
-other projects that work: When I click on the bottom-left 'launch chrome against localhost(testApp)' and then I click 'launch chrome against localhost' on the top menu (which is redundant and stupid) Chrome opens and returns instantly to the first breakpoint.
-on this project Chrome opens displaying the file list in the working directory via localhost. Then, when I select the html file the js code runs ignoring the breakpoints. Go figure...
What 'confused' VScode 'Debugger for Chrome' extension is that I had named the html file with the name of my project (eg myproject.html) When I renamed it as 'index.html' it stopped displaying the working folder contents but instead of returning to the VScode breakpoint, the breakpoint turned to the following icon:
unverified breakpoint
When I put the "main.js" file inside a 'src' folder and updated the path in the html file, everything worked. That is more Sherlock Holmes investigation than programming. About 3 hours were wasted...
Is it possible to spoof Chrome plugins?
I noticed that their names are stored in Preferences and Local State file in /Users/mainuser/Library/Application\ Support/Google/Chrome/Default/Preferences and /Users/mainuser/Library/Application\ Support/Google/Chrome/Local\ State respectively (on Mac), but manually changing the contents of these files gets treated as file corruption. Any idea how to spoof it?
Plugin information are publicly available and are easily inspected with something like this:
var x=navigator.plugins.length; // store the total no of plugin stored
console.log(x);
var txt="";
for(var i=0;i<x;i++)
{
txt=navigator.plugins[i].name;
console.log(txt);
}
I assume you want to modify an extension that you have installed on your machine in order to improve it.
You can use the Developer Mode and load the modified extension:
Extensions that you download from the Chrome Web Store are packaged up
as .crx files, which is great for distribution, but not so great for
development. Recognizing this, Chrome gives you a quick way of loading
up your working directory for testing. Let's do that now.
Visit chrome://extensions in your browser (or open up the Chrome menu
by clicking the icon to the far right of the Omnibox: The menu's icon
is three horizontal bars. and select Extensions under the Tools menu
to get to the same place).
Ensure that the Developer mode checkbox in the top right-hand corner
is checked.
Click Load unpacked extension… to pop up a file-selection dialog.
Navigate to the directory in which your extension files live, and
select it.
Alternatively, you can drag and drop the directory where your
extension files live onto chrome://extensions in your browser to load
it.
If the extension is valid, it'll be loaded up and active right away!
If it's invalid, an error message will be displayed at the top of the
page. Correct the error, and try again.
Paranoid about browser fingerprinting I guess.
If you want hide navigator.plugins list, see this plugin :
https://github.com/bcaller/plugin-privacy-chrome
See content.js#L27 :
properties.plugins = vecw({}, true);
The "real" fix is to stop the enumeration of plugins for everybody, so there is no fingerprint information (after everyone upgrades):
https://bugs.chromium.org/p/chromium/issues/detail?id=271772
If you hide navigator.plugins, that is also an identifying (single bit) feature that will make you stand out since there will be very few users who hide navigator.plugins. Which is why you'd want to spoof.
From another answer, from #Hors Sujet, https://github.com/bcaller/plugin-privacy-chrome is a great place to start how to program a spoof. You'll want to look like the vast majority of Chrome users (I'm not sure that actually exists, though.)
But what you likely really want is EFF's Privacy Badger.
Start here to see the number of bits you can be fingerprinted by:
https://panopticlick.eff.org/
And then install Privacy Badger from here:
https://chrome.google.com/webstore/detail/privacy-badger/pkehgijcmpdhfbdbbnkijodmdjhbjlgp
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
I'm using a third party statistics library which seems to have loads of issues. It's both large and compressed, so it's not particularly easy to debug. I'm using the Chrome Dev Tools and I was wondering what options there might be for ranking functions by the number of calls by their name, maybe? I thought the answer was the Profiler tab, but the profiles I captured are only documenting the JS files referencing "line 1" in long chains.
This thing is freezing my app and I'd rather avoid making changes to their code as much as possible, even if its for the sake of debugging. I'm happy to clarify anything that's not clear.
EDIT: I seem to remember a recent demo of chrome dev tools somewhere showing a timeline that depicted function blocks stacked vertically based on the time increment going horizontally called "flame charts" or something similar... That would be ideal, but I can't remember the link right now for the life of me. Not opposed to using Canary on this one at all if anyone knows what this tool is?
The latest video about DevTools is here http://youtu.be/x6qe_kVaBpg?t=19m44s
It covers different topics about DevTools and includes a section about CPU profile too.
So, you need to record a cpu profile and look into it.
Also you can use FlameChart view on it.
You can click on an item in BottomUp or TopDown or even a FlameChart bar and see the function body in the Sources panel.
If you sources are minified, as in the screenshot, then you can press a button in the status bar of Sources panel. It looks like two curly braces {}. Then DevTools will format the sources.
and that action will affect all the links to the source file in all other places like Timeline, CPUProfile etc. As example in the first snapshot you saw a function O.Pk that was at line 778 of minified version of the script. After pretty printing the source file the link to the function was changed automatically. Now it is pointing to the line 15871.
Looks like the answer is the "Timeline" tab. Seems to work in regular chrome. I set the tab to record just before I triggered the action that caused the hang, once the hang stopped (took about 20 seconds), I stopped recording and used the left and right selectors to zoom in on the master timeline (at the top) where I saw an longer execution period (at the top) with "Events" selected.
From there I just expanded the dropdown and I got what I was looking for. (I blurred out the js filenames to avoid singling out the library) but I'm including a screenshot.
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.