Web Inspector Redesign
Posted by Timothy Hatcher on Tuesday, September 30th, 2008 at 4:06 pmIt has been nine months since our last Web Inspector update and we have a lot of cool things to talk about. If you diligently use the Web Inspector in nightly builds, you might have seen some of these improvements, while other subtle changes might have gone unnoticed.
Some of the Web Inspector improvements were contributed by members of the WebKit community. We really want to get the whole community involved with making this the best web development tool available. Remember, most of the Web Inspector is written in HTML, JavaScript, and CSS, so it’s easy to get started making changes and improvements.
Redesigned Interface
First and foremost, the Web Inspector is now sporting a new design that organizes information into task-oriented groups — represented by icons in the toolbar. The toolbar items (Elements, Resources, Scripts, Profiles and Databases) are named after the fundamental items you will work with inside the respective panels.
Console
The Console is now accessible from any panel. Unlike the other panels, the Console is not just used for one task — it might be used while inspecting the DOM, debugging JavaScript or analyzing HTML parse errors. The Console toggle button is found in the status bar, causing it to animate in and out from the bottom of the Web Inspector. The Console can also be toggled by the Escape key.
Error and warning counts are now shown in the bottom right corner of the status bar. Clicking on these will also open the Console.
In addition to the visual changes to the Console, we have also greatly improved usability by adding auto-completion and tab-completion. As you type expressions, property names will automatically be suggested. If there are multiple properties with the same prefix, pressing the Tab key will cycle through them. Pressing the Right arrow key will accept the current suggestion. The current suggestion will also be accepted when pressing the Tab key if there is only one matched property.
Our compatibility with Firebug’s command line and window.console APIs has also been greatly improved by Keishi Hattori (服部慶士), a student at The University of Tokyo (東京大学) who tackled this area as a summer project.
Elements Panel
The Elements panel is largely the same as the previous DOM view — at least visually. Under the hood we have made number of changes and unified everything into one DOM tree.
- Descend into sub-documents — expanding a frame or object element will show you the DOM tree for the document inside that element.
- Automatic updates — the DOM tree will update when nodes are added to or removed from the inspected page.
- Inspect clicked elements — enabling the new inspect mode lets you hover around the page to find a node to inspect. Clicking on a node in the page will focus it in the Elements panel and turn off the inspect mode. This was contributed by Matt Lilek.
- Temporarily disable style properties — hovering over an editable style rule will show checkboxes that let you disable individual properties.
- Style property editing — double click to edit a style property. Deleting all the text will delete the property. Typing or pasting in multiple properties will add the new properties.
- Stepping for numeric style values — while editing a style property value with a number, you can use the Up or Down keys to increment or decrement the number. Holding the Alt/Option key will step by 0.1, while holding the Shift key will step by 10.
- DOM attribute editing — double click to edit a DOM element attribute. Typing or pasting in multiple attributes will add the new attributes. Deleting all the text will delete the attribute.
- DOM property editing — double click to edit a DOM property in the Properties pane. Deleting all the text will delete the property, if allowed.
- Metrics editing — double click to edit a any of the CSS box model metrics.
- Position metrics — the Metrics pane now includes position info for absolute, relative and fixed positioned elements.
Resources Panel
The Resources panel is a supercharged version of the previous Network panel. It has a similar looking timeline waterfall, but a lot has been done to make it even more useful.
- Graph by size — click Size in the sidebar to quickly see the largest resources downloaded.
- Multiple sorting options — there are many sorting methods available for the Time graph, including latency and duration.
- Latency bars — the Time graph now shows latency in the bar with a lighter shade. This is the time between making the request and the server’s first response.
- Unified resource views — clicking a resource in the sidebar will show you the data pulled from the network (not downloaded again), including the request and response headers.
- View XHRs — the time and size graphs also show XMLHttpRequests. Selecting an XHR resource in the sidebar will show the XHR data and headers.
Scripts Panel
The previous standalone Drosera JavaScript debugger has been replaced with a new JavaScript debugger integrated into the Web Inspector. The new integrated JavaScript debugger is much faster than Drosera, and should be much more convenient.
From the Scripts panel you can see all the script resources that are part of the inspected page. Clicking in the line gutter of the script will set a breakpoint for that line of code. There are the standard controls to pause, resume and step through the code. While paused you will see the current call stack and in-scope variables in the right-hand sidebar.
The Web inspector has a unique feature regarding in-scope variables: it shows closures, “with” statements, and event-related scope objects separately. This gives you a clearer picture of where your variables are coming from and why things might be breaking (or even working correctly by accident).
Profiles Panel
The brand new JavaScript Profiler in the Profiles panel helps you identify where execution time is spent in your page’s JavaScript functions. The sidebar on the left lists all the recorded profiles and a tree view on the right shows the information gathered for the selected profile. Profiles that have the same name are grouped as sequential runs under a collapsible item in the sidebar.
There are two ways to view a profile: bottom up (heavy) or top down (tree). Each view has its own advantages. The heavy view allows you to understand which functions have the most performance impact and the calling paths to those functions. The tree view gives you an overall picture of the script’s calling structure, starting at the top of the call-stack.
Below the profile are a couple of data mining controls to facilitate the dissection of profile information. The focus button (Eye symbol) will filter the profile to only show the selected function and its callers. The exclude button (X symbol) will remove the selected function from the entire profile and charge its callers with the excluded function’s total time. While any of these data mining features are active, a reload button is available that will restore the profile to its original state.
WebKit’s JavaScript profiler is fully compatible with Firebug’s console.profile() and console.profileEnd() APIs, but you can also specify a title in console.profileEnd() to stop a specific profile if multiple profiles are being recorded. You can also record a profile using the Start/Stop Profiling button in the Profiles panel.
Databases Panel
The Databases panel lets you interact with HTML 5 Database storage. You can examine the contents of all of the page’s open databases and execute SQL queries against them. Each database is shown in the sidebar. Expanding a database’s disclosure triangle will show the database’s tables. Selecting a database table will show you a data grid containing all the columns and rows for that table.
Selecting a database in the sidebar will show an interactive console for evaluating SQL queries. The input in this console has auto-completion and tab-completion for common SQL words and phrases along with table names for the database.
Search
Accompanying the task-oriented reorganization, the search field in the toolbar now searches the current panel with results being highlighted in the context of the panel. Targeting the search to the current panel allows each panel to support specialized queries that are suited for the type of information being shown. The panels that support specialized queries are Elements and Profiles.
The Elements panel supports XPath and CSS selectors as queries in addition to plain text. Any search you perform will be attempted as a plain text search, a XPath query using document.evaluate() and a CSS selector using document.querySelectorAll(). All the search results will be highlighted in the DOM tree, with the first match being revealed and selected.
The Profiles panel supports plain text searches of the function names and resource URLs. Numeric searches are also supported that match rows in the profile’s Self, Total and Calls columns. To facilitate powerful numeric searching, there are a few operators and units that work to extend or limit your results. For example you can search for “> 2.5ms” to find all the functions that took longer than 2.5 milliseconds to execute. In addition to “ms”, the other supported units are: “s” for time in seconds and “%” for percentage of time. The other supported operators are “< ”, “<=”, “>=” and “=”. When no units are specified the Calls column is searched.
In all the panels pressing Enter in the search field or ⌘G (Ctrl+G on Windows and Linux) will reveal the next result. Pressing ⇧⌘G (Ctrl+Shift+G on Windows and Linux) will reveal the previous result. In the Resources, Scripts and Profiles panels the search will be performed on the visible view first and will automatically jump to the first result only if the visible view has a match.
Availability and Contributing
All of these things are available now in the Mac and Windows nightly builds. Give them a try today, and let us know what you like (or don’t like).
If you would like to contribute, there are some really interesting tasks in the list of Web Inspector bugs and enhancements, and other contributors in the #webkit chat room are pretty much always available to provide help and advice.
September 30th, 2008 at 6:15 pm
Very impressive as usual.
September 30th, 2008 at 6:32 pm
Awesome! Love the style property and metrics editing. It would be nice to be able to drag-drop/re-order the Styles, Metrics and Properties panes (I’d like Metrics on top, sometimes). Thanks for your hard work!
September 30th, 2008 at 6:38 pm
Adam, please file an enhancement request at http://bugs.webkit.org/ like the blog post suggests.
September 30th, 2008 at 7:12 pm
Thanks Mark. Filing now.
September 30th, 2008 at 7:52 pm
Such beautiful work! Thank you for recognizing that developers deserve good aesthetics too.
I’m assuming you guys don’t know when Apple will bundle this with an official Safari release. Or do you?
September 30th, 2008 at 9:50 pm
용우의 생각…
더 이상 safari에서 디버깅 하기 힘들다는 말 못하겠는뎅….
September 30th, 2008 at 11:23 pm
@Brandan: There’s a very strong chance this will be included in the next major release of Safari.
September 30th, 2008 at 11:33 pm
That’s awesome, great job guys. I love using console.dir !
I’m using firebug less and less everyweek.
October 1st, 2008 at 1:02 am
Really great job
Quick question: Are there any plans to add syntax highlighting to the source view (cmd-shift-u / ctrl-shift-u)?
October 1st, 2008 at 1:21 am
@Mark_S: The “View Source” window is part of Safari, rather than part of WebKit. If you’d like to file an enhancement request for Safari, please visit http://bugreport.apple.com/.
October 1st, 2008 at 1:32 am
Cool!
Two improvements I’ve noticed that you didn’t mention: the inspector now works when JS is disabled (it didn’t previously), and you can resize the inspector up and down when it is docked to the web page.
October 1st, 2008 at 3:30 am
Webkit s’offre un nouvel inspecteur…
Je ne suis pas un fervent admirateur des produits d’Apple mais force est de reconnaître qu’ils savent y mettre la manière, le nouveau Web Inspector est de la même veine.
Pour les besoins professionnels, j’utilise Safari pour vérif…
October 1st, 2008 at 8:40 am
DAMN, the graphs look good. How are they made, if I may ask?
October 1st, 2008 at 10:16 am
@henrik: One of the coolest things about the Web Inspector being written with HTML and CSS is that you can actually use the Web Inspector to inspect itself. Give it a shot and find out
October 1st, 2008 at 2:42 pm
wow! what a huge improvement, beautifully done.. looks to be a viable alternative to FireBug.
October 1st, 2008 at 4:30 pm
This looks fantastic. I love it!
October 1st, 2008 at 4:59 pm
Now we have firebug for firefox and a new full featured version of web inspector for safari. I wish microsoft would help debug/workaround the poor CSS support of IE with an equivalent free plugin for IE … So many webdev hours spent going crazy about peekaboo bugs and their friends …
October 1st, 2008 at 5:03 pm
woweee! I may never need to open Firefox again, this looks absolutely fantastic at first glance. Such a MASSIVE improvement over the previous Web Inspector.
This is going to be invaluable, especially given all the problems I’ve had with Firefox 3 and the Firebug 1.2b lately. Thank you WebKit team!
October 2nd, 2008 at 3:07 am
no word about linux port? webkit guys probably forgot fact, where the webkit came from. thank you for your care
October 2nd, 2008 at 3:26 am
WebKit works fine on linux…
October 2nd, 2008 at 6:58 am
When will you be able to edit properties in computed styles like Firebug??? This is one of the major roadblocks for me using this as a Firebug replacement…
October 2nd, 2008 at 7:39 am
Firebug does not let you edit computed styles. They let you edit the same style rules we let you edit.
If you could edit computed styles, then they wouldn’t be “computed”, now would they?
October 2nd, 2008 at 7:57 am
Wow! The new Web Inspectors makes a web developer’s heart beat faster. Hopefully I can use my browser of choice for developing, too.
Here are some things which would make the Web Inspector my best tool:
1. Pease display POST/GET variables of XHRs next to the request header.
2. The GUI is could be enhanced. There are too many clicks needed to reach common used functions. It start with the shortcut Alt+Apple+I. There should be a shortcut which can easily be used with one hand. What about Apple+U?
3. XHRs and other loaded resources should be displayed at the top of the “Resources” list in the sidebar because they might be of interest. This avoids scrolling.
4. Well, I know its easy to say this: A HTML/CSS validator.
October 2nd, 2008 at 7:59 am
We may be talking about different things here.
What I’m referring to is when there is inline style= within the HTML, it shows as computed in Webkit versus editable in FB. I can use FB to tweak a computed style elementwhereas I cannot in Webkit.
October 2nd, 2008 at 8:19 am
I see. That isn’t the computed style, that is the style attribute. You can edit it in the Web Inspector, we trigger editing on double-click.
See the blog post:
“DOM attribute editing — double click to edit a DOM element attribute. Typing or pasting in multiple attributes will add the new attributes. Deleting all the text will delete the attribute.”
October 2nd, 2008 at 8:31 am
Ahhh.. it sounds like Webkit does have the same capabilities for editing CSS and inline styles then? If that is the case, then its just a matter of getting used to how WK works versus FB. Then all that is missing are things like PixelPerfect (FB plugin for designers) or FirePHP which add some nice features to FB.
I’m going to give WK a couple of weeks and see if I can make the switch… I like FF3 but, it’s not a native mac app and can be very resource hungry…
October 2nd, 2008 at 8:48 am
Great Job.
Just a little thing is missing. The line for the selected rule in the css file.
I use FB every day and this information is very useful if I have to work in a css file with 900 or more lines.
October 2nd, 2008 at 11:28 am
One last observation here.. What’s been so attractive about FB for people like myself;
(let’s classify my group of people as a “web handyman”, we can code but we’re not great at it, we can design rudimentary web graphics and we’re not great at that either but we can do a good job, we install web sites which we’re really adept at doing, and we love to take templates or premade site templates and tweak those)
and there are WAY more of us than you realize doing great sites and FB has been a web-blessing allowing us to tweak website layouts without having to edit CSS and HTML then save it and refresh it.
If webkit and subsequently Safari were to really cater to this group like FB does, you would have a smash hit on your hands. A lot of us use FF and FB exclusively due to this lack of site tweaking ease that FB permits. We’re not experts by any means but, we do make a good living doing what we do.
Thoughts?
October 2nd, 2008 at 5:29 pm
@ugocasalone: You should file a feature request at http://bugs.webkit.org for anything you find lacking (or just wrong
) in the WebInspector
October 2nd, 2008 at 9:17 pm
I’ll add to @ugocassione comments.. besides line numbers, if you hover over the css file name, it will show you the location of the CSS file so you don’t have to guess which one it is.. Webkit is already pulling this info and if you click the css file name, it changes to the resources window. It would be nice to have the file location display by simply hovering over the CSS file in the Elements window on the right..
October 2nd, 2008 at 9:46 pm
So I guess its okay to talk about it now, even tho this is in the Safari 4 previews (and under NDA for ADC members)?
Also, I don’t like that you can’t attach the JavaScript debugger to other WebKit apps anymore (or am I missing something)? Safari is not the only place we need to debug JavaScript, especially now that the JavaScript engine is so fast it can almost be considered an application framework (esp. if you are Google) and thus breaks free of Safari for RAD and custom browsers or HTML-based content display (Mail.app, Adium, iChat, a certain networking setup/utility product I work on all day).
October 3rd, 2008 at 1:15 am
“So I guess its okay to talk about it now, even tho this is in the Safari 4 previews (and under NDA for ADC members)?”
From what I was told, you can talk about any features in the Webkit nightlies and specify that they are Webkit nightly features, rather than features of the Safari browser version which shall not be named, with the completely unpredictable version number following the current major revision. Quite a lot of these features have been in the nightlies for some time.
October 3rd, 2008 at 3:57 am
Neo: you can use the inspector in other WebKit apps. Go back to the original inspector blog post, it has the defaults write command to enable it.
October 3rd, 2008 at 10:08 am
For me, as a dummy: in FB I can tab through all properties: http://getfirebug.com/screenCSS-learn.gif
And if I doubble click in the empty area next to the properties it adds a new emty property. It autocompletes as I type, i.e. backg gives me background, if I press up or down it makes further suggestions, like background-image.
Is that possible here too, or am I missing something?
October 4th, 2008 at 1:26 am
@webjive “It would be nice to have the file location display by simply hovering over the CSS file in the Elements window on the right.” We already do that, hover the link and you will get a tooltip in a second with the full location,
October 5th, 2008 at 9:10 am
@webjive: I appreciate the very apt words about web handymen. I’ve made a young, but fairly successful career from being able to do all of the little things that can take a website from an idea to fruition. Nevermind the fact that I’m not especially great at any of these skills, but at least I’ve got the toolset to create and administer websites. Of course, firebug has been a huge part of this toolset.
Quick question; I’m using Safari 3.1.2. I’ve got the web inspector up and running, but could you please explain how to edit the styles? You mentioned double-clicking. That’s not working…Am I missing something?
Thanks!
October 5th, 2008 at 10:29 pm
jpelker: These changes aren’t in Safari 3.1; you’ll need to wait for an update, or use the nightly builds available from nightly.webkit.org
October 13th, 2008 at 11:30 pm
can’t help myself to say it’s such a nice tool~
thanks
October 14th, 2008 at 12:58 pm
Absolutely brilliant changes!
The only request I’d make would be to see an option to view colours in CSS as hex rather than just RGB.
Thanks