Hacker News new | comments | show | ask | jobs | submit login
Chrome Devtools Tips and Tricks (mo.github.io)
293 points by molsson 555 days ago | hide | past | web | 37 comments | favorite



The author's frustration with the lack of customizable shortcuts is my biggest issue with chrome devtools as well. This is especially frustrating when I just want to pop a debugger statement in the middle of a node.js unit test so I can step through things, but node.js requires that you use the browser for debugging. (EDIT: apparently there is an IDE from jetbrains[1] that lets you do this too) This past Friday I started poking around to see what it would take to write a terminal-based browser in the style of the python debugger and found that the v8 team at Google has been working making the debugger separable from the browser since at least February of this year[2].

[1] https://www.jetbrains.com/webstorm/

[2] https://github.com/nodejs/node/commit/14174a95a597cac7b848fe...


We've recently been cleaning up our keyboard shortcut implementation in DevTools. The end goal is definitely enabling customizable shortcuts and we're definitely targeting those step-wise debugging usecases. Star to get updates: http://crbug.com/174309


Also, visual studio community edition is free[1] can debug nodejs with an extension[2]. And the capability is integrated into VS Code[3] which works cross-platform.

Those and webstorm/intellij are the ones I have experience with. But most of the time, I just use the CLI debugger -- it's not hard.

[1] https://www.visualstudio.com/en-us/products/visual-studio-co...

[2] https://github.com/Microsoft/nodejstools

[3] https://code.visualstudio.com/


Which CLI debugger are you talking about? I thought one didn't exist


It has a built-in debugger that you start using `node debug /path/to/script`. See more here: https://nodejs.org/api/debugger.html


> node.js requires that you use the browser for debugging

wat? :/

Node.js does not require you to use the browser for debugging. But you're probably referring to node-inspector, which uses Chrome or Opera. I personally find webstorm to be wayyy easier debugging node unit tests specifically.


~~Is webstorm usable outside a jetbrains product? In particular, on a headless server?~~

EDIT: That was a dumb question. This IDE looks pretty cool. I'll check it out. But I still want something that I can run headless.


In addition to the standard debugger, WebStorm also give you SpyJS for Node[1], which is a Tracer/Reverse debugger.

[1] http://blog.jetbrains.com/webstorm/2014/08/tracing-debugging...


Since debugging is over a TCP connection, you only have to start the nodejs process with the debug flag, and then plug the address and port into whatever debugger you're trying to use.


>The little magnifier glass icon that shows you which CSS class/selector in what CSS file that ultimately decides the styling for a specific element and CSS property.

FML. I hope this is a recent feature, I have wasted so much time missing something like this while trying to reskin a fairly large web app.

I suspect that Chrome devtools is so good because Google has access to a large number of web developers within the company to directly talk to. Chrome seems to have a solution for all the problems that developers face. My recent experiences with Firefox devtools has been bad. Specifically Firefox was not displaying js files loaded dynamically ( through require() ) in the debugger even though they were present in the page inspector.


You can also use brackets editor to see the source of css styles for a particular element


If you happen to have a link to a page where the Firefox devtools are not doing what they should, and happen to remember which version of Firefox you were running at the time, I would very much appreciate that!


It is already present in Mozilla bugzilla : https://bugzilla.mozilla.org/show_bug.cgi?id=1044522


That bug is marked as a duplicate of a bug that's been fixed for close to a year now. So either you're seeing a different issue, or your recent experience wasn't all that recent. If it's the former, I really would appreciate more details so we can fix it; if it's the latter, give it another shot. ;)


Maybe I should go more into detail. The problem we had was that some charts and graphs in our application was not showing up only on Firefox ESR 38.3. Examination of the problem revealed that rickshaw was not loaded. The console had thrown an error from rickshaw.js saying that d3 was not loaded. But rickshaw.js was not available in debugger console !

The reason I did not raise a bugzilla was because the issue was intermittent ( ! ) and also I cannot share the whole application user interface with outsiders yet. Anyway, my working conjuncture is that these files are loaded from callbacks of AJAX requests and the problem happens when the callback for loading rickshaw fires before the callback for loading d3 has had a chance to fire. We ended up loading d3 manually as a workaround. But it is important to show rickshaw.js in the debugger since it enables us to set breakpoints there.


Hmm. The bug you link to was fixed in 36, so in 38.3 you're seeing a different problem.

I understand the difficulty in filing bug reports on pages that you can't show people yet. If you get to a point where you _can_ show it to people (even just a limited set, not the whole world), and you're still running into the problem, the bug report would be very much appreciated.


OK. Thanks for your response regarding this.


My latest find: if you right-click a variable that was output in the developer console, you can choose "Create Global Variable" to access it. It's super-useful combined with lodash to inspect large arrays of elements, for example.


Also, if you're paused at a wait point, the console has access to local scope, so you often don't even need to create a global variable, just start using the local ones directly.


Yup. You can then use the copy command on that variable so you can paste and view the large array or json in your text editor of choice.

`copy(temp1)`


Something that saved me a lot of time recently is that from the network request list, you can right click the request and "Copy as cURL" to get a full cURL equivalent command of the request.


You can format minified js code by clicking the pair of curly braces in the bottom left corner of the source window. This has saved me a lot of headaches.


Some more tips on Chrome DevTools here: https://umaar.com/dev-tips/


Hi Umar, I subscribed a little while ago after discovering some of your tips on Twitter. They've been really useful, especially with the animated GIFs... thanks very much for making them.


Appreciated, glad you enjoy them.


In terms of finding code that runs when clicking something, there's a extension Visual Event which works really well. https://chrome.google.com/webstore/detail/visual-event/pbmmi...


I've been using chrome since it's beginning but just recently really digging into it. There's a ton of cool stuff in it. Just recently discovered the "snippets" section which lets you save a piece of js code and rerun it whenever you want (under Sources -> Snippets -> rightClick - add).

I'm also working on my first chrome extension if anyone's interested in helping or could give some feature requests/advice. https://github.com/jxm262/consoletap


This is a great tip, thanks!

Using it to store this snippet which invokes the debugger when something tries to redirect you from the page, allowing you to inspect the state and any network requests (last time I checked, "preserve log on navigation" was buggy and didn't preserve all details of the request from a previous page):

  window.addEventListener("beforeunload", function() { debugger; }, false)


Paul Irish (https://news.ycombinator.com/user?id=paulirish) should write a book about this topic.


Addy Osmani is a great resource as well: https://plus.google.com/+AddyOsmani/posts


I just recently found out about Chrome Devtools' multiple cursor support by accident, and didn't know about the navigation shortcuts at all until now.

Once it gets shortcuts customization support, I think I might try to use it as my main editor for a while and see how that works out. I have it open almost constantly during development anyways, so using it as an editor would get rid of that redundant dedicated editor window and streamline my workflow by quite a bit.


Another tip: you can click and hold the "dock" icon in the upper right corner. You can't right-click it.

(I never understand the UI design paradigm here)


It has been fixed in unstable / canary. The selection is now inside an overflow menu.

Which brings me to another tip: in a multi-head setup, having devtools in an undocked window in a separate screen is very nice.


> "Just like atom"

No, just like Sublime Text. Atom copied these features and shortcuts from ST.


It's "like" both editors. He's not attributing its origin, just comparing the feature.


Or like TextMate? Not sure which came first now.


Nice list of new niceties in Dev Tools. Thanks for sharing!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: