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]
