Google I/O 2011: Chrome Dev Tools Reloaded

Irish: We're here.
We're gonna be talking about the Chrome Developer Tools.
Uh, my name is Paul Irish.
I am a developer advocate on the Google Chrome team.
Feldman: And I'm Pavel Feldman,
software engineer working on Chrome Dev Tools
and WebKit Web Inspector.
Irish: So we're gonna be talking about, uh,
what's inside the dev tools,
a lot of features that you might not be aware of,
a lot of features that are brand-new to it, uh,
and landed within the past 12 months.
So hopefully you'll--the things you'll learn in this session
will make you a more productive developer.
I should point out, if you want to follow along to the slides,
there's a few links inside of them.
The short link is right there, speaker feedback beneath that,
and if you feel like tweeting, the hash tag's below.
Feldman: But before we start,
Paul, can I ask a couple of questions here?
Irish: Please.
Feldman: Please raise your hand if you know what Firebug is,
just to calibrate.
Irish: Hmm. Feldman: Okay, that's a lot.
Now who uses Firebug on a regular basis?
Oh, that's a lot.
Now who knows what Chrome Dev Tools is?
Oh, that's good.
And who uses it on a regular basis?
That's a fair share. Irish: Yeah.
Feldman: Should we just skip it all and go straight to the Q&A?
Irish: Yeah, yeah, yeah. A lot of you guys know this.
All right, well, the first thing that I wanted to point out
is that the Chrome Dev Tools
is--is a web app.
And to show this, let me-- let me just show you this.
So this slide deck here is also a web app,
and I'm gonna bring up the dev tools on the Inspector.
Let me dock this down here.
Now can you guys in the back see this text down here?
No, probably not.
Let me, uh, let me bump that up for you guys.
Go over here. Scroll down.
Do, do, do.
Yeah, there we go.
Better for you guys? Feldman: [laughs]
Irish: Good. Okay. I think we'll leave it about there. Yeah.
So, uh, yeah, what I want to point out
is that the dev tools,
it's just made out of HTML, CSS, and JavaScript,
all these panes, all these views.
It's not a lot of C++ black magic voodoo going on.
It's just--the things that you're familiar with
are the same things that built this.
[clears throat] So, um, now that we got that out of the way,
this is what we're gonna talk about.
Uh, we're gonna talk a little bit about styling and CSS,
go into the network layer side of things.
We're gonna cover a few tricks
to make you more productive inside the console,
Um, dig into script debugging.
And then we're gonna cover
a brand--a couple brand-new features, uh,
that we're unveiling today.
Um, yeah.
But for those of you that, uh, that didn't raise your hand, uh,
when we asked who's familiar with the Chrome Dev Tools,
I'm gonna briefly summarize what it is.
Uh, the developer tools
are a set of integrated browser tools
available right inside the browser.
There's no extra add-on, no extension needed.
Um, the whole goal of them
is to make you a more productive developer.
If you're using them as effectively as you can,
uh, you're able to do a lot of manipulation to the page,
iterate really quickly,
um, and--and make your changes right here
in-line in the--in the browser.
You don't have to do that
"go back to the file, save, refresh,"
kind of trial-and-error dance.
You can make it all happen iteratively
right inside the browser.
Um, there's a lot of functionality
regarding DOM, styles, um, script debugging.
Uh, there's a console.
There's audits so you can get performance data.
There's, um, even you can get the--the rendering...
[laughter] Irish: Thanks very much--
the rendering, like, data in the timeline view
and then the network layer.
And, well, um, there's a lot of really good stuff.
Feldman: Okay, that's good. Irish: Thanks for that.
Feldman: [laughs] [applause]
Irish: Okay. [clears throat] Feldman: [laughs]
Irish: So what we're gonna do first
is we're gonna talk a little bit about styling.
Start off kind of with the basics--
So let's see.
I have a, uh, I'm using command Alt--command Alt + I
to, uh, toggle up and down,
but I could also just right click and hit "Inspect" here
to select these

s.
So I got these

s.
They're, uh, they're looking okay,
but I think they need a little bit of love,
so I'm just gonna add some style to them.
Uh, I'm gonna double click in this empty area right down here,
and we can add a new style.
And so, I don't know, I'm gonna try out "background red." Yeah.
So I'm tabbing.
You'll notice I'm tabbing between
the property and the value here.
You don't have to type a colon. It's nice and easy.
I can tab down and set up a new one.
That's all well and good.
I also notice that I do have
auto completion here on the property, right?
So you can save a little bit of time.
You can just type "back," hit tab, go over to the value.
But now we also have auto completion
on the value names, too.
So this is good especially with longer, uh, color names
like, um, one of the most delicious colors--
papaya whip. [laughter]
If I was making a smoothie web site,
I would put papaya whip all over it.
Also really helpful, um, with colors
that you just kind of forget the name of sometimes.
It's like, uh, fuchsia is--
fuchsia--fuch--fuch--
oh! fuchsia.
Oh, magenta. [laughs] [laughter]
Irish: Yes, in fact, fuchsia and magenta
are the exact same color.
Fuchsia's kind of tough to remember sometimes.
But, um, I don't know.
You probably don't use named colors a whole lot,
and the cool thing here is that you can click this little, uh,
the color swatch
and just iterate through the different color formats.
So I can toggle over to RGB or HSL.
How many people familiar with, uh, HSL,
hue, saturation, and lightness?
One of my favorite ways to manipulate color.
So now I can go over here.
I'm gonna go into the saturation.
I'm just gonna hit "down" on my keyboard,
bring down the saturation.
I could hold down Shift and jump by 10s.
There we go.
Bring down the brightness, the--the lightness.
Get a nice deep purple here.
It's pretty good.
So I can use that and kind of tweak it as I like in HSL,
and then maybe I'll go back to HEX
and then copy this into my style sheet,
'cause that's what I need to be using.
So you could be doing a lot of manipulation right in here.
Now other times
you're--you're adding styles in here,
but there might be a case
where you just don't have a style in here to tack onto.
So right now I'm selecting
the current slide that we're on,
and I might just not have any hook to add on--on--
add on my style to.
So up here in the top right I can hit this little gear icon,
and here's "New Style Rule."
And the cool thing
is that the--that the Dev Tools automatically guesses
at what would be the most appropriate selector
for what I currently have selected,
and it's got "Current," current class,
and that works for me.
So I'll add a little style to that.
I like this slide. I feel good about it.
We're gonna add an outline.
I'm gonna make it 15 pixels, solid, and, um,
one of my favorite colors--
yeah... [laughter]
Irish: Pretty dope color.
Yeah, I think that-- that works out well for me.
Yeah, so, uh,
so we're adding styles completely, uh, on the fly
with brand-new selectors.
So that's pretty nice.
Um, I'm gonna move forward.
Now the thing is is that I just made all these changes
live inside the elements field.
Now if I look over at these changes,
I'm gonna click over to "Resources,"
and you'll see right here
the changes that I just made over in "Elements"
I'm now seeing here on "Resources"
highlighted in purple
to let me know that this stuff has now changed.
Um, so what's happening
is all the changes that you make over in "Elements"
we keep track of them now, um, which is really cool.
So you have your full style sheet view
plus the changes that I was making,
like iteratively on the fly, kind of bite-size changes,
but now I get it at the style sheet level.
And then you'll see down here,
this little arrow next to "styles.css."
We're actually keeping revision history
of all the changes that you're making.
Pretty rad, right?
So I could right click, actually, and be like,
you know what, I'm just gonna go back to how things were,
revert back to that.
Or you know what, I was kind of liking what I was doing.
We'll stick with that.
And you have full revision history, too.
That's pretty cool.
And this means that you can be doing
a lot of your development inside the browser.
But then you get the problem, "Okay, I made the changes.
"I like where it's at.
"Now do I go over here and kind of select these
and copy and paste it back into my style sheet?"
You know, I've done this a lot. There's a better way.
So you can actually just right click here
and click "Save As"
and so immediately saved that file back to the file system,
overriding your old style sheet.
So you can just do a nice quick area loop
without even going back to your editor.
[applause]
Irish: Yes.
So that's pretty cool,
but, um, right now-- I don't know.
I'm looking at this page. It still looks a little drab.
I-I think it needs something else.
So I'm gonna open up, uh,
this pattern gallery here.
Yeah, so this is actually, um,
a collection of CSS gradients
made by... who's a friend and developer
and a few other people.
These are just made out of CSS gradients.
Um, and she's making these--
these really impressive patterns, really cool.
So I'm gonna click into this one.
I like this one a lot.
And, uh, you'll see this is actually the gradient
that constructs this pattern.
Now I'm gonna select this
and go back to my slides,
go up here and select the body.
Um, this looks good.
I think I'll just double click here, paste,
add that in.
Looks pretty sharp to me.
Um, I could also, you know,
the--the thing that we're really excited about now
is that while I have
the new changes right here over in the style sheet
I can now actually double click,
and I have free full--
freeform style sheet editing.
So I can just add--manipulate this style sheet
just like as in an editor,
so, you know, adding line-- white space to just make sure
that this stuff looks the way that I want it to,
or perhaps I'm just gonna get rid of this completely
and go back to a background
all of--I don't know.
Any--any color recommendations?
woman: Purple.
Irish: Purple. Like it.
Yeah, so I can do all my editing right here
without even having to go back to the browser,
and all those changes as well are kept in revision history.
So I can kind of stick around right inside this UI.
Pretty dope.
So I'll revert back here.
Don't need to use this going forward.
All right, so I've covered a little bit of styles.
Uh, we're gonna transition
into a little bit of looking at things from the network layer.
Feldman: Right. Thank you, Paul.
So we've been looking at the styles,
and styles is when you're visually designing your page.
So you're spending your time in the elements panel here.
Now, uh, imagine that we have designed our page,
and, uh, we are happy with the--how it looks like.
Now we need to deliver it to our client,
and when we're saying "delivering to a client,"
we mean network,
and when we're saying "network,"
we always care about the latency.
Now let me show you what developer tools
has to say about the network, uh, on a demo.
For that, uh, let me open
the new tab in here.
I'm opening dev tools using command option I as Paul did
and navigating to the network tab.
Now let me jump to gmail.com,
and let's focus on the network panel in here.
Now the network panel, uh, highlights, uh,
the network and direction.
For each request that was issued against the server
we have an entry in here,
and these entries have a nice timeline.
This is information
about the timing for particular requests.
Uh, we can get a bird's view
on the network interaction in here and see the status codes.
And for example in this case
we can see that it took us, uh, two redirects
to get to the page
that actually was served with the content.
So GMAIL was moved permanently,
and it moved us to the mail.google.com,
and mail.google.com said it moved temporarily
to the following location.
And the first location
that has actually been served with us with the content
is the service log in,
And the reason for that was that I was not logged in.
I was not authenticated.
Now we can see that each of these entries have tabs
with the content for them--
Headers, Content, Cookies, and Timing--
and let us go through them real quick.
Now the "Headers" tab shows the real information
about the HTTP headers that were sent to the server--
[speaking indistinctly] query parameters,
either for form or get parameters,
response also available in the raw format,
and cookies information.
So that's kind of a raw HTTP headers,
as raw as you can get.
Now the "Content"
is a syntax-highlighted content preview
of the resource that has been loaded.
And we syntax-ly highlight, uh,
HTML, JavaScript, CSS.
"Cookies" is the cookie information
about this particular request to the network.
So in case of service log in,
we have sent a number of cookies to the server,
and it actually sent us
a couple of cookies to send back.
And you can see that these cookies are HTTP and secure,
and HTTP and secure cookies
are the ones that are not available to JavaScript,
and it means that with the developer tools
you can see everything about cookies
including things that are not visible
with a document that cookie object.
And "Timing" is the information, detailed information,
about the timing involved with this particular request.
And we can tell you the timers for DNS, proxy, SSL,
request, response, connecting, blocking,
pretty much everything.
And if we go back to this timeline view,
you can hover over the elements
to see what are the timers for the particular request.
Like for this, in this case,
we were waiting for 36 milliseconds
before we actually started receiving a response.
And pictures are similar in other cases as well.
Now that's, um, pretty, um, pretty different.
That's pretty simple functionality.
The important thing about it is that the information
that is highlighted in here is taken from the network stack.
And as you might know, Chrome has its own network stack,
Chrome's platform unique to all the platforms.
And thanks to that network stack
we can get a very precise timing information
and data information,
take it right from the network stack and bring it to you,
and the data is accurate in nanoseconds.
Now that's very important
when you are dealing with a page load.
Like in this case, this page was loaded within 500 milliseconds.
But as web evolves,
we see more and more AJAX applications,
more and more, um, JavaScript-enabled active apps,
and in those cases, um, load time is also important,
but there are other pieces of runtime
that are all equally important from the latency standpoint.
And when we're interested
in what's happening after the page load,
uh, we can look at the timeline.
Now let me show it to you by example.
I am starting to record whatever is happening in here,
Uh, and I'm looking for purple flowers at Google,
and I stop recording
and zooming into an area of interest.
Now that's a timeline panel,
and the timeline is recording
whatever is happening on your web page,
all the events, native events, that are happening there.
And we have three categories for these events--
Loading--blue, scripting--yellow,
and rendering--pink or purple, depending on the projection.
It's more of a bluish in here.
Now, um, you can see all of these records here on the left
along with their detailed information about timers.
Stack trace is involved,
um, memory information,
uh, position on the screen
when it's associated with a Paint event,
Um, stack traces for loading and, um,
for sending res--requests and receiving responses.
So a lot of information about these events
is highlighted in here.
So what you do is you find a long bar
that is taking a lot of time.
For example in this case, the send request,
the solid part is a synchronous time
that was actually spent while we were waiting for the response,
and the semitransparent part is the time that has been taken
by the implications of this call.
For instance, request has been served,
and it led to some layouts,
some subsequent resource requests,
some JavaScript executions.
So it's fairly interesting.
Oh, and in this case we have evaluated a script.
We can jump to script and back
and see what was happening while the script was evaluating.
We can see garbage collection, timers install.
A lot of information about what's happening
on a single timeline.
So now you can measure not only your initial page load time
but also the different actions,
the user interaction details, etcetera.
So that's our network story and our latency story.
And with that, I'll hand it over back to Paul.
Irish: Great. Feldman: Okay.
Irish: So I think it's about time to transition
into a bit of JavaScript.
So I want to talk a little bit about the console.
So you're probably familiar
with our good old friend console.log.
But I do want to point out that console.log
actually has, you know,
it can accept more than just one argument.
So you might be "im in this function."
But you know, feel free to pass it,
you know, document, uh, nodes on the document,
uh, booleans and numbers and arrays.
All these things work.
So console.log is a lot more friendly than you might think.
But in addition to the console logging functionality,
there's a bit going on that--
functions that are available to you
right within the console,
and that's called the Command Line API.
So this is documented over on Firebug's wiki.
Firebug introduced a lot of these,
but now, uh, the Chrome Dev Tools,
Opera Dragonfly, IE dev tools
support a good number of these.
So there's things like, um,
well, there's "clear(),"
and there's other things like "dir()."
So sometimes I might have a node element here,
and if I log on an element to the console,
I can kind of explore the tree right inside in-line here,
kind of nice.
But sometimes you want kind of a different view
of that information,
So the dir() method can give you that.
So with the case of an element, it'll give you the DOM view,
so the DOM properties of that node.
So that's dir().
Now you might also have this node here
that you're working with in the console inside the script,
and you actually now need to go view that
over in the elements panel, right?
So you can just use the "inspect()" function,
and then you just hop over
immediately over to the elements view
with that element selected.
Now sometimes you have kind of the reverse situation
where you have an element selected in "Elements,"
but then you want to access that via "Script."
So I'm gonna bring up the console right here.
I actually can just hit the Escape button.
Escape toggles on and off the console on all of these.
Um, so I'm gonna bring that up,
and I'm gonna type "$0."
So $0 refers to whatever element
I have selected, uh,
up in the "Element" DOM view.
So it works just like a regular reference,
so I could do, let's say, um,
maybe "$0.outerHTML."
Sure.
And we just get that.
Sometimes you get a message logged out to the console,
and then you actually want to take that output,
and you need to go, you know, paste that somewhere else
in your editor or something like that.
So while you can, you know, try and make sure that you get,
you know, select all this--
it can be a little awkward,
so there's a nice little handy convenience function for you,
which is the copy() method, right?
And so you can just type "copy()," pass it a string,
and, uh, go over to your editor and just paste it.
And so you can immediately just throw things in your Clipboard,
save it--save yourself a little bit of time.
So there's a few cool things inside the console.
But while we're dealing with JavaScript,
let's talk a little bit--
a little bit about script debugging.
So Pavel's gonna take care of this.
Feldman: Yes. Thanks, Paul.
So we've discussed visually designing a page
with the styles.
We were talking about delivering the page to the client.
Now Paul was talking about the console interaction,
which is actually an interaction with a page at runtime
while evaluating expressions against running page.
Now when you're debugging your page,
um, it's not always enough.
You want to post the JavaScript execution
to see what's happening within the virtual machine,
what are the object's states at the moment,
and for that we have the debugging capabilities
in the Chrome Developer Tools.
Let me open this demo page
where I'll be demo'ing the debugger.
This is a closure component that is called HoverCard.
Uh, it is showing nice pop-up messages
when I'm moving my mouse over the objects, over the elements.
You might find it familiar
because the one is used, um, in GMAIL.
Now I'm opening the dev tools
and switching to the Script step.
Now I happen to know, uh,
that the particular file name
and the line number of the code that gets executed
when I'm moving my mouse over the elements,
so let me quickly jump there.
I'm selecting the "Select File" drop,
and I start typing HoverCard, so it quickly brings me there.
Now I'm pressing "Command + L" on the Mac
or "Control + G" on Windows and Linux
to jump to a particular line.
Now let me quickly set a breakpoint in here
and hover my mouse over.
Now the dev tools are saying
that we are paused on a JavaScript breakpoint.
And on this breakpoint
we can see this tag with the stack frames.
For each of the stack frames
we can see local closure and global scopes.
We can explore objects in here.
We can also hover over elements to see their values
at this particular time while JavaScript is stopped
and explore them in here.
Now you can also use console together
with the, uh...
um... [speaking indistinctly]
to dump the values in here in-line.
Now, um, we have conditional breakpoints.
We have stepping,
all standard stuff that IEDs and debugging tools have.
But, um, breakpoints is not always enough.
Let's say that you're looking at this page for the first time,
and you don't know the file name and the line number
that I've been using.
Let's say you want to learn how this event log
is getting populated as I move my mouse around.
For that, let me reveal this element
in the "Elements" panel
And no context menu on it
and choose "Break on Subtree Modifications."
Now what I've done, I added a breakpoint
on a DOM node,
and I said, "I want to stop whenever this DOM node cha--
or any of these standards change.
Now let me hover my mouse over an element,
and we stopped again.
In this case, we have a different stack,
and we can explore all the path that our code has done
to get to that condition,
and we can see that the selected line
is trying to appendChild to an element.
So that's the exact place where something is changing,
uh, with our DOM.
Now, um, I'm scrolling to this user-friendly message in here,
and it says it "paused on a 'Subtree Modified' breakpoint
set on" a particular element "because a new child was added."
So you have detailed information
of what node was breakpoint added upon
and what node has changed.
I can release the execution,
and I can see that the DOM is being modified twice
while I'm moving my mouse over an element.
Now that's--we call this functionality DOM breakpoints.
It allows you stopping whenever DOM changes
or nodes are added or removed,
and it's very handy when you know
the port in the UI that is getting changed
that you'd like to explore.
Now we've talked about regular breakpoints,
where you can set a breakpoint on a line, the DOM breakpoints,
where we can set a breakpoint in a node.
Sometimes you don't have a place in the UI that gets modified.
Still, you have some clue on what's happening on a page,
and you'd like to explore it.
Like in this case I'm hovering my mouse over an element,
and it takes, like, a second or half
for this pop-up to show,
so I think there must be some timer involved.
So what I do is I expand this event list
or breakpoint sidebar in the "Scripts" panel,
and under "Timer" I click "Set Timer."
Paul, you made these fonts really big.
Now dev tools does not look that pretty.
Anyways, so I'd like it to stop whenever the timer is installed.
And you can see that there are different kinds of events,
uh, browser events, page events, that are happening
and that can be--that can have
a JavaScript execution stopped upon.
But we're interested in the timer at this moment.
So I'm hovering my mouse over it again,
and in this case I stopped on a timer installation.
So you can see that the object got a timeout installed,
and that's a global default timer object.
It's a global object in our case.
Now I can again explore the stack trace
and learn what has happened in here,
look at my, uh, local closure
and, uh, global variables in here.
Now that's pretty cool,
'cause even if you only to know
the type of event that's happening,
like a keyboard or a mouse event,
you can jump straight into the line of the code
that is doing something associated with that event.
But that's not everything.
Now we mentioned you don't even know the event name.
You have no clue on how your page is working.
Still, you'd like to explore it.
Still, you'd like to have breakpoints
and put pointers to the source code.
And we're using timeline for that.
Again, I star recording my scenario.
I move--oh, I should have removed this breakpoint in here.
So back to timeline-- clearing it
and repeating my scenario
and stopping recording.
Now these are events, mostly mouse move events in here,
but I can see one large thing.
So there has been a mouse over event
that has a 0 self time
so it immediately released the control,
but it has implications
that were taking about half a second.
Let's, uh, explore it.
So what happens is there is some parsing involved
when I am assigning to inner HTML.
It turns out to be an expensive operation
because it showed up in here.
Then there are styles recalculated.
That's because I am using scroll top and scroll height
that are actually kicking the layout.
And then I can see that the timer has been installed,
and that's the same line
that we were stopping it on on a breakpoint.
And then what I can see
is that the timer has been installed for 500 milliseconds.
It has ID 80.
And, uh, when I trigger it,
it did some parsing again.
It did style recalculation.
It removed itself from the timer.
So that's kind of pretty much everything
that this scenario was doing.
Now imagine, I had no clue on how this page was working,
and now I have a bird's view on a sequence of events,
synchronous and asynchronous bound together,
that show me the complete picture
of the page runtime
together with the timers, resources,
style--styles, etcetera.
So that's our debugging story,
but debugging story is not only about the exploring a code.
It is sometimes about fixing bugs.
So let's go back to the line we started.
It was HoverCard,
uh, 208.
And let's say I found a bug in here,
and I'd like to fix it.
Now what happens, uh, usually you need to edit a script,
deploy to a server, reload the page,
go to the same place in the UI,
do your action again,
and see whether you'd fixed it or not.
Now we have something better for you.
Uh, just as with the CSS, you double click in here,
and you start editing your source code.
In this case, I'll be, uh,
adding my microelement to the console.
I press "Command + S"
to commit changes into the virtual machine
and hovering my mouse over elements.
And you can see the console gets populated with the values.
Now console is not very interesting.
Let's try changing something,
and in this case I'd like this element
to get a new background color.
I'm gonna use Paul's favorite one.
I don't really know what it means.
It's called BADA55 or something. I'm not local.
So committing it again
and now as I hover my mouse over elements,
they get painted.
So what happened under the hood
as I was editing my function body,
uh, the highly optimized feed code
in the Chrome browser was de-optimized
and got into the runtime.
So all the instances of this function
were modified instantly and stepped in place as I typed.
And that's very useful when you're deep in the context,
and you don't want to reload a page
just to repeat something or change the behavior slightly.
So that's pretty much it, uh, for the debugging.
And with that, I'll--
Irish: Actually, um, you have one more thing.
Feldman: Oh. Oh, sorry. Yeah. I have one more thing.
And, um, that's about the google.com, right.
So I always wanted to know how it works,
but I couldn't really read it through.
Irish: That's a cool dance up there.
Feldman: Right. But do you know how it's implemented, though?
Irish: No, I don't. It's...
Feldman: It's window Google static something.
Irish: Mm.
Feldman: Okay, so anyways,
now we have this small button in the status bar,
and I click it, and I see a nice...
[applause]
Feldman: Um, what's cool about it is
that breakpoints are also going to work as I reload the page,
and I can step through the nice pretty printed Google code,
and we can finally know how it works.
Okay, well, that--back to Paul.
Irish: Great. Thanks, Pavel.
All right, so let's go back to here.
[clears throat]
Another thing that we're really excited
to share with you guys today is remote debugging functionality.
So the easiest way for me to show this to you
is, um, just show you the demo, I guess.
So I'm gonna bring up the HoverCard over here.
That works.
But you'll notice we're running Chrome Canary right here,
and when we launched Chrome Canary,
we actually launched it from the command line,
and we use this little guy right here--
"remote-debugging-port"--
and we specified that as 1337.
And so what that lets us do
is say that, you know what,
this, uh, the dev tools,
we're gonna, you know, turn that into a web server.
Um, we're gonna kind of expose that
so that we can log into that from another place.
So I'm going to, I think,
launch, uh, Chrome.
Stable release.
And I will load up port 1337.
Okay, so you're seeing over here two items,
and they should be familiar to you.
They're the two tabs that I currently have open.
So I'm gonna open up this tab.
And remember-- remember before when I said
that the dev tools is just a web app?
I mean, I'm just viewing it in Chrome right here.
It's--it's a web app.
But the cool thing is that these are the dev tools
of this browser, two separate browsers.
And you'll notice it just works, you know.
I have full control over this browser.
So this is something that's really exciting to us.
The--the cool thing about this is that this has been--
all this work has been happening at the WebKit level,
which means that all mobile WebKit browsers going forward
now have the ability to--
for you to control their developer tools
from your desktop browser.
Pretty cool.
[applause] Irish: Agreed.
So we're really excited about this.
You can actually test it out today.
It's available in the RIM PlayBook.
Uh, but we're excited because there's a lot of things
in the mobile situation where there's, like,
network information that's just so difficult to get a hold of,
and all the network timing information that you saw
from Pavel earlier you have available.
You have the full functionality, all the debugging, everything.
So we're really excited in moving forward from that.
Feldman: Okay, thanks.
Now that we are announcing things,
uh, we have something else to announce.
And we are trying to do our best
to support every feature in the Chrome Developer Tools,
but sometimes it's just not... [speaking indistinctly]
and sometimes there's just too many good ideas
to put into the product.
And to address that,
we are introducing an extensibility API.
So it's a Chrome extension API that allows you, um,
extending Chrome,
and we have three types of APIs that we're revealing today.
First is panels.
Uh, with that API you can add a panel
to the developer tools window.
With your own I-frame content that is going to, uh,
be talking through the page and instrument it.
Uh, you can also add sidebars to the "Elements" panel
with that API.
There's an audit API where you can implement the, uh,
audit suite that we were not talking about,
but you can add the audit suite
for, like, model readiness or readability
and make it a part of the, um, Chrome Developer Tools.
And the third one is the resources.
Uh, we all are interested in the latency
and everything that work related,
so you're exposing all the network information
by means of HAR format in these resources APIs
so that you can analyze resources,
load time, and latency
and express some information to the user in the panel
that you're adding to the developer tools.
Now these APIs are Chrome extensions APIs.
Uh, they are currently in the experimental phase.
It means that we are looking forward for your feedback,
and we are going to process it
for a couple of Chrome iterations.
Um, it is now six weeks per iteration.
And then we'll make them stable.
So we want your feedback,
and here's the way to provide it.
Irish: So we've been showing a few features here today,
and a lot of them are pretty new features.
So if you want to play around with this stuff,
um, we really recommend trying out
the Chrome developer channel or the Canary build.
The dev channel updates about once a week,
The dev channel about daily.
Uh, but you can be getting the latest and greatest stuff.
The pace of development on the dev tools is extremely fast,
so, like, every week you're seeing new features
landing inside your browser, which is really exciting.
If you are doing that and you find a bug,
you know, we definitely want to hear about that.
We also really, really want to hear your feature requests
so please just head on over to new.crbug.com.
File a bug against Chromium.
Just mention dev tools, and we'll get right on it
and see if we can make it happen for you.
Now we've been using a few keyboard shortcuts in here.
Pavel was showing a go-to-line down here.
There's a few, uh, different ones,
and you might forget them.
You can actually just type a question mark
when you're in the dev tools,
and it pops open a nice little heads-up display
to remind you of some of the keyboard shortcuts.
But there's--there's a few more
than the ones that are shown there,
and we recommend you check out
the Chrome Developer Tools documentation site.
So here there's full docs on nearly every feature
including a full listing of the shortcuts.
Uh, we talk about the brand-new remote debugging capabilities,
and we have a lot of videos as well
to go deep dive into the functionality
within the dev tools.
So definitely recommend you guys check that out.
Other than that, I think that's it for us.
Thank you guys very much for coming.
[applause]
Irish: We'll be doing a little bit of Q&A.
Uh, we have microphones here and here.
Um, so if you have any questions for us
about the Chrome Developer Tools,
uh, we would love to answer them for you.
Yes, sir.
man: So when I get a 500 level response,
uh, in the network monitor,
but it's giving me content that describes the error,
when I click on the "Content" tab
it--it's always blank.
But if I go and just type that URL in my browser,
I will see that content.
Feldman: Yeah, so-- man: Is--
Feldman: Yeah, we're currently working on it.
There's a new feature called, uh, JSON Pretty Print
so for all XD charts you're going to get
a printed JSON content with [speaking indistinctly] tree,
the same thing we're doing for all the error messages
so that for all 500s and such
we are going to render HTML in a separate tab.
I think we'll have it, like, in a couple of weeks,
so check out the dev channel, and you'll have it there.
man: Okay. Thanks.
man: Uh, the time limit, the tab,
is it possible to replay those timeline events?
Feldman: Is it possible...
Irish: To replay, uh, the timeline data as it...
Feldman: Uh, no, you can't replay it at the moment,
and you can't, uh, save it yet.
We're working on saving first.
And, uh, but you could process that data
with the, um, remote debugging API that we have now
so that you can attach to Chrome
and on the low level, on the JSON level,
you can record all the actions
that are taking place on the page,
analyze them, and use them for for your continuous integration
compared to the later builds, execution and such.
And for that you should check out the remote debugging page
where were are revealing the remote debugging protocol
that you could connect to Chrome with.
man: Oh, thanks.
man: Hi, yeah, thanks a lot for that.
That's really awesome stuff. Irish: Thank you.
man: Uh, this "Save As," I saw that.
Um, do you, like, an automatic save,
um, where you can just, like,
save to the same file so it remembers it, basically,
for CSS and JavaScript?
Feldman: So it's kind of the first time we are
entering the IED space in here,
and we don't go to--we don't want to go too far there.
We are a debugging tool.
Uh, what we--
and it is also kind of a privacy--security concern,
uh, to write to your hard drive
from within the sandbox environment,
so we want it to be very explicit.
And, uh, but talking about the saving as you go,
uh, we are exposing the remote debugging protocol now,
and we expect, uh, web IEDs or Cloud IEDs
to talk to Chrome by means of that protocol
and allow you editing things live
so that you will be in the environment,
in the IED environment,
still talking to Chrome
and having all these capabilities.
But there are no plans of silently saving to disk
from within browser yet.
man: Okay, thank you. [laughs]
man: Do you have any plans for any, uh,
tight integration with GWT-built applications?
Feldman: So we've shown you the Pretty Print functionality.
Now the way it works, it pretty prints
the JavaScript source code.
It parses it and pretty prints it.
And then as it pretty prints it, it creates a mapping,
but in the old one,
the [speaking indistinctly] one and the pretty printed one,
and as you debug it,
we kind of use this mapping
to show you breakpoints on the pretty printed locations
but set them in the [speaking indistinctly] locations
in the virtual machine.
Now we can use the same machinery
to work with the translated languages such as GWT.
So we are going to support mappings
for the compiled languages into JavaScript.
It's just not in the build yet.
But the Pretty Print is a very solid step in that direction,
and it is in our plans.
man: Thanks.
Feldman: Yeah, please.
man: You mentioned that, uh,
it's available for the RIM PlayBook to be able to, um,
play with the DOM over here from my MacBook over here.
So but is that a feature that's rolling out later
on other devices,
or is it something that I could also play with on this?
Irish: Uh, that's the new Samsung, the one that you got?
man: Samsung, yeah.
Irish: Currently, uh, that's not available,
uh, on the Honeycomb builds.
Um, and, uh, so right now it's available on PlayBook,
but we expect, you know, future iterations
of all--everything that uses mobile WebKit
to be able to have that feature.
man: Great. Great. That's very exciting.
man: The one feature
I've always missed in the Chrome Developer Tools
is when you do a search
it only searches the current file you're in.
It does not search every single file,
which is a feature in Firebug I love,
and I-I have a really hard time using Chrome Developer Tools
because of that one feature.
Feldman: Yeah, so, uh, that's a popular thing.
man: I'm sure it was.
Feldman: You can search everything
with the "Resources" panel.
So it'll search every resource including JavaScript and CSS
and bring you multiple results.
So kind of technically it is possible.
Not too useful, I agree.
Now we are not--
so the feature that we're missing, really,
is a search results pane
so that you could search like in the ID
and get a lot of a list of results you could jump in,
uh, in the bottom.
The thing is that the doc mode that we're using
that is very popular, it is--
we don't have too much real estate vertically already,
so a search pane does not work that well.
So we are looking for the solution for that,
and we know that it is a popular request,
but before that we just say
please search in the "Resources" panel.
You'll find it there.
And then go to any other resource or other panel
where you can use it.
man: The way that--the way it works in--in--
in other choices that if you just do a search
you just start going through each file individually.
So you start in the one file
and just keep on going through each--each--
you have to hit "Enter" a lot of times,
but you eventually do get to it, you know.
Feldman: Right. Right. Except for in this page...
man: Right. Feldman: There's just
too much of them, so when we want search results pane.
man: Okay. Feldman: Web is moving
so we need kind of more real estate for search results.
man: All right, thanks.
man: Is there any way in the Chrome Developer Tools
to remove all breakpoints at once
instead of going through
and manually removing one at a time?
Irish: Yeah. Feldman: I think so.
Irish: This guy right here. Feldman: That deactivates them.
You want to remove them.
man: 'Cause a lot of times the guys on the team
will actually set up, like, ten breakpoints for something
and finally fix a bug and then have to go
and manually click and remove every single breakpoint.
I know it's trite, but... [laughs]
Feldman: So let me, yeah, so, um, interesting fact.
Uh, we're working on Chrome Developer Tools upstream.
It means that we are committing our code
into the WebKit repository.
And, uh, you can add a file bug into the crbug.com
or into the WebKit.org.
And you'll find all the useful shortcuts
on our documentation page,
and we encourage you to file the bug there
or file a bug on the crbug.com and star it.
Because the way we are fixing the bugs
and feature requests is we sort by number of stars,
and if the request has a lot of stars,
and I would foresee that this one would,
as well as the search one before,
we'll just fix it. man: Cool.
Thank you. Feldman: Okay, thanks.
Okay. Irish: Cool.
Feldman: Yeah. Irish: I guess that's it.
Well, thank you guys very much for coming. Appreciate it.
Feldman: Yeah, thank you. [applause]