Things I didn’t know about the WebKit inspector | Hacker News Reader

Things I didn’t know about the WebKit inspector

blog.joocode.com

247 pointscopesc51 comments

I love tip articles! Here are some more that I use heavily (note that some of these might be Google Chrome only at the moment)

The gear in the bottom right of the Chrome inspector has a lot of useful options, such as emulating touch events and preserving the console log upon navigation.

The Watch Expressions persist across tabs and I keep "this" as the top watch expression all the time. It makes for an easy quick check when debugging to make sure that you're in the scope you thought you were, and you can always use the dropdown to inspect all the properties of the current class.

CTRL+G works in the sources tab (go to line)

You can highlight some code and right click -> Evaluate and it will run that selected line in the console for you. Alternatively you can highlight the code and press CTRL+SHIFT+E

You can remotely use the web inspector for Chrome Mobile: http://www.youtube.com/watch?v=s4zpL4VBbuU

There's a useful shorthand: In the console you don't have to type "document.getElementById('blah')" to get a reference to the blah ID'd element. Instead you can just type "blah" in the console, and even though autocomplete doesn't show it, pressing enter will return the element with ID blah!

~~~~~

As an aside, developer tools like the inspector are the reason my pea brain is allowed to have a love affair with the weird little language that is JavaScript.

Thanks to the console the amount of time it takes to whip up a five-cent program with JavaScript without even leaving my browser, heck without even leaving this tab is just astounding to me even after all these years.

One thing I noticed is that more than the language itself, the tools that I use while building things in the language are what really make them a pleasure to use. If I wasn't using (Chrome's) web developer tools I'd probably consider JavaScript to be a nightmarish corpse of a language that punishes the slightest of typos with a silent malicious grin, as code execution carries on as if A.blah = 5 and A.blsh = 5 were both equally worthy of existing to the JS compiler/interpreter. Only by the grace of tools is JS tame at all.

(So if you're reading this Webkit/Inspector developers, thank you.)

'this' in the watch expressions and the element id trick are handy!

> There's a useful shorthand: In the console you don't have to type "document.getElementById('blah')" to get a reference to the blah ID'd element. Instead you can just type "blah" in the console, and even though autocomplete doesn't show it, pressing enter will return the element with ID blah!

That's crappy, it's DOM0 aliasing. Use `$` if you're not using jQuery, it's an alias for document.getElementById. And there's $$ for document.querySelectorAll and $x for xpath queries.

See http://getfirebug.com/wiki/index.php/Command_Line_API for the rest of the command-line API.

> The Watch Expressions persist across tabs and I keep "this" as the top watch expression all the time. It makes for an easy quick check when debugging to make sure that you're in the scope you thought you were, and you can always use the dropdown to inspect all the properties of the current class.

An other good introspection method when debugging: expressions entered in the console execute in the current scope.

After reading the article and your comment, I'm encouraged to give Javascript another chance. Your guess at how you would consider Javascript if you didn't use Chrome's developer tools is actually spot on to how I find it... I am a Firebug user and not a fan of Chrome's tools, but if Firebug has these kind of JS capabilities I've yet to discover them. I must confess, I haven't really looked hard enough, and it looks like JS deserves another shot.

Speaking of web inspectors, did anyone else notice what a tremendous broken piece of crap the one in the latest version of Safari is? It's downright scandalous!

I had to manually roll back Safari to 5.1.7 to get the old one back.

I will give Apple credit for keeping me hooked on Safari since they're bookmark and history sync across all their devices via the cloud is top notch.

I gave it a cursory glance but haven't had much cause to really use it yet (though I did get some good use out of the console keeping a history of log files). What kind of issues have you been having?

Half the features missing, impossible to navigate.

That's actually completely false. Just about all of the features are there, but they have been reorganized a lot. It seems like they're trying to align the organization of their inspector more with the way the debug tools in XCode work, so that the experience is unified across them. It's a bit tough to get used to if your habits are with the old inspector, but it's actually not too bad once you start getting the hang of it. Just a rearchitecting of your brain map.

I kind of like it but the console is broken-slow. a simple console.log(foo) doesn't draw anything for a second or two after the event fires and even then it's empty for another moment while the inspector decides what to draw. Very odd.

If you log into Chrome, your bookmarks, history, plugins, settings, etc. will sync across all Chromes that you log into with the same user/pass.

Thanks, but the chrome on my iPhone/iPad leaves something to be desired

Compared to Safari? Really? I'm honestly surprised, as an iPhone user who had to put up with Safari for 3 years. The only nice feature about it is the Readability-powered Reader button.

Safari is the only browser on iOS with JIT enabled.

Doesn't excuse its irritatingly outdated UI.

not if you jailbreak :P

search for "nitrous" on cydia

If Jailbroken and you have 99 cents, you can install Nitrous in Cydia to get nitro everywhere. It gave me 3.5x faster performance on Sunspider.

But even if not, how many mobile websites use heavy JS? Chrome appears to use page pre-fetching as well, or at least that's what I gather from the "preload webpages" setting.

The $0 thing will save me a lot of time. I often spend a while figuring out how to select a specific element with DOM queries, or assign it a special ID and then do the whole document.getElementById malarkey.

This blew my mind! I've always thought there should be a way to do this, and now to learn that there always has been!

Even better: there is a selection history. $1 get you the item you selected before the one that is currently selected, $2 the one before that, etc.

Oh man, this is the best link and comment thread all week. Thanks!

Several cool tips in here I didn't know about.

Regarding the element drag and drop: it's a really awesome way to brainstorm redesigning a UI, but I've found if I mess with it too much it starts behaving weirdly and getting confused about whether the elements are in their old or new spots, and I have to refresh and start over. Still an awesome feature for productivity.

>> Console, write more-than-1-line commands: shift-enter does the trick. Pressing enter at the end of the script runs it.

You need to shift-enter every line, not as usable as Firefox/Firebug. Also tab is still not working. This is the reason why I am still using Firefox for development purpose.

http://code.google.com/p/chromium/issues/detail?id=35487

Agree, that could be definitely improved!

The upcoming Snippets functionality has a great story for this. You can turn it on in devtools experiments, but it's likely gonna get revised a bit before it ships.

Hi Paul, thanks for your information and I will definitely check it out when it is ready.

Can anyone point to a guide for using the web inspector in Safari 6? It looks like it could be powerful, but it is not as user-friendly as the Safari 5 and Chrome inspectors. It feels like a step back.

Apple's documentation has been updated for Safari 6's new Web Inspector: http://developer.apple.com/library/safari/#documentation/app...

Has anyone figured out how to set a breakpoint in the actual page (not a .js file)? There are no line numbers in the inspector to click on. I complained to Apple. I also can't figure out how to add script files to the sources tab in the new webkit version of the inspector. Also clicking on the line numbers in the resources tab of the new webkit inspector no longer sets a breakpoint. I've had to go back to 5.x since I can't set breakpoints where I need to... Ideas?

Command-K also clears the console, just like it does in terminal. Awesome stuff. Unfortunately the `x = _` trick to save the output of the last command to variable x does not work, but that would be really awesome if they put that in!

`$_` is coming to WebKit soon: https://bugs.webkit.org/show_bug.cgi?id=93377

Already in Canary!

I've always felt that firebug has been a little bit better than the chrome developer tools. Now I might reconsider and start using chrome for development instead. The ability to add new css rules in the element view something I've been dreaming about for a long time. The ability to write more than one line of javascript without enabling a different mode is also absolutely fantastic.

Is there a similar list for firebug? A strong advantage of firebug is of course that it's has a bunch of nifty extensions. Which one do you prefer?

"Break on DOM modification" is going to be a big time saver for when an ajax call fetches a bit of html with a <script> in it.

Don't do this.

Hey, sometimes shit happens, you know?

Write "debugger" in your source code, chrome will drop you into debugging mode when that line is read. The console will be in context of your "debugger" statement.

Here's one I stumbled into the other day: You can inspect the inspector!

This is in Chrome for Windows (haven't tried Safari or Chrome for Mac).

Hit F12 to open the inspector.

If it is docked, click the undock icon so it's in a separate window.

Make sure the focus is on the separate inspector window (click its titlebar to be sure), and hit F12 again. This opens another inspector window where you can inspect the first one.

In Chrome when viewing a js file the "{ }" button (pretty print) in the lower left will un-minify the file. Most useful for debugging live sites.

very useful, but i really wish Chrome allowed you to replay a HTTP request from the network tab. I just want to right click on e.g a POST request, and send it off to the server again. Whenever i need to do this at the moment i have to switch to LiveHttpHeaders in firefox, which is a pain.

Charles (www.charlesproxy.com) makes this kind of thing pretty easy. Well worth the money, in my book.

why not use firebug for that in firefox?

i use chrome as my default browser, it's just a pain to have to switch for this kind of thing.

if you're switching to firefox for livehttpheaders, switch for firebug. ???

It's a long shot, but worth a try:

I loved using Safari's inspector for for trying out CSS selectors. It seems that both for Chrome and Safari, only searching for xpath seems to still work. Am I missing something or did that really get removed?

How did you "try out CSS selectors"? $$ is supposed to do that (it's essentially a shortcut to document.querySelectorAll), does that not work anymore in recent versions?

You could just enter the selector in the top right search box in the elements tab.

I just noticed that Chrom seems to have updated, it works again: https://skitch.com/marc.seeger/em6tu/hacker-news-add-comment

Right click in Sources tab on gutter and you can add breakpoint, and conditional breakpoint. Condition is any javascript expression and is evaluated to Boolean. If true - debugger breaks.

Well damn, I only knew one of those. Good article.

CTRL+SHIFT+F searches through all the scripts. I use this primarily to navigate through code i.e CTRL+SHIFT+F "function showDialog("

I think I prefer Command+Shift+O that the article suggests in this case.

the difference is that CTRL+SHIFT+F works from every tab in the chrome inspector and searches globally i often just copy paste the line i want to debug from my editor in there be it a function or declaration within a function.

Reply on news.ycombinator.com