Mobile Chrome Office Hours: Tools for Mobile Web Development

Uploaded by GoogleDevelopers on 22.08.2012


MALE SPEAKER: Shanghai GDG is a very
interesting developer community.
FEMALE SPEAKER: I'm glad somebody
has asked this question.
MALE SPEAKER: This is where the magic happens.
FEMALE SPEAKER: This is primarily a
question-and-answer show.
So if any of you out there would like to ask questions--

PETE LEPAGE: All right.
Well, welcome.
So I'm Pete LePage and welcome to the first of a series of
Chrome Mobile Hangouts.
With me here, we've got Boris.
I'll let you introduce yourself.
BORIS SMUS: Hey, I'm Boris.
We're both from Chrome Developer Relations, so mostly
working on mobile these days.
So back at Google I/O, Chrome for Android and Chrome for iOS
became available.
And we're really excited about both of those, because it
really brings a great browser to the mobile environments.
So today, we want to talk about a couple of things that
we think is pretty interesting.
Boris is going to start off talking a little bit about
high DPI stuff.
So if you've been building web applications or websites, and
you've used them on either one of the new MacBooks that have
Retina display or on a iPad3, you've seen
the high DPI stuff.
And the web looks a little bit different if you're using one
of those devices than something else.
And then I'm going to talk a little bit about some of the
debugging tools that you can use on Chrome for Android when
building these sites.
And then we'll take some of your
questions through the moderator.
So Boris, I'll pass it over to you.
You just had an article about high DPI--
BORIS SMUS: We published an article this
morning, "HTML5 Rocks".
Many thanks to Alex who stayed up late in
Sydney to get that out.
So I just want to sort of be more specific here.
The high DPI problem doesn't just apply to iPads and
MacBook Pros with the new Retina displays.
It's actually a general problem on the web.
There's a lot of devices that now have device pixel ratios
of greater than one.
I'll talk a little bit more about what
that means in a second.
But it's an Android issue.
It's a Windows Phone 8 issue.
And it's an iPhone issue and iPad issue.
So this high DPI question needs to be solved generally
on the web and is being worked on generally.
So there's this big thing about Retina displays, but
that's just branding.
And it's also more than just, OK, say, I've got this high
DPI image or a regular, but there's also something about
choosing images based on screen size too in there.
It gets a little complicated, actually.

Well, basically what you want to do is you want to serve the
best quality image as quickly as possible.
But the thing is what quality means sort of depends.
You have like just pure resolution, like crispness of
the pixels.
And then you have things like for a small display, you want
to show up maybe a different image than for large display.
Like say you have Obama speaking at some conference or
something like that, maybe if you have a large screen,
you'll show the pedestal, you'll show
Obama's face as well.
But on a small screen, you might just show his face,
because there's not much real estate.
I think in your article that was just published--
and we can put the link up for that.
But in that article, if you scroll down, you actually have
a really good visual description of that, where in
the foreground, you've got like person and all of the
background image, like where they're standing, where
they're talking.
But on a small screen display, that person
just gets lost, right?
And you don't want to show all of that.
I actually don't have that in the article.
But the article more focuses on just the resolution.
I might be thinking of a--
BORIS SMUS: That was something else.
PETE LEPAGE: --different article.
Another article, I'm sure, had that.
I know the exact image, actually,
you're talking about.
But anyway, the way this whole resolution aspect works, if
you ignore the art direction of bits, it's sort of
complicated on the web, because there's so many
different kinds of browsers out there and so many
different devices.
Like on iOS, for example, you just have 1x and 2x displays.
So when you're talking about 1x and 2x,
what does that mean?
Can you--
So basically a 1x image--
well, let's talk about displays first.
A 1x display has pixel density.
That's whatever the display's pixel density is.
So if I've got--
BORIS SMUS: For an iPhone, the pixel density of the iPhone
3G, the pre-4 one, is like 163, actually.
PETE LEPAGE: So that's the pixel density.
So like in one inch, there's about 163 pixels.
BORIS SMUS: Exactly 163.
Well, about on average.
So with a 2x display, there's twice as many pixels in the
same space.
PETE LEPAGE: So roughly, there's like 320
pixels in an inch.
So that's the 2x display of a iPhone.
Of course, the actual number of pixels depends on what the
initial 1x was.
So like an iPad is slightly less dense.
A MacBook Pro is even less dense.
But the 2x equivalents are doubled.
All right.
BORIS SMUS: So that's the way that that works.
It makes it really simple for Apple developers
to solve this problem.
Android also has a similar concept.
But because of the variable display densities,
there's no 2x notion.
So you sort of need to cover the whole gamut of
PETE LEPAGE: So does that mean that like it might be 1.5, or
1.3, or 1.--
BORIS SMUS: Exactly.
PETE LEPAGE: It could be anywhere in that number.
I mean we're probably going to start seeing greater than 2x
as well going forward from-- well, maybe not from Apple.
I can't speculate there.
But it's certainly likely to increase up to the point where
you can't see any pixels anymore.
PETE LEPAGE: That would be really cool.
That would be really neat.
BORIS SMUS: We're getting close already.

You have to look really hard to find them.
So that's sort of the story.
Android solves the problem by letting you provide like four
different images.
So you have a very small, medium, biggish, and extra,
extra large--
PETE LEPAGE: Now this is if you're doing an Android native
So that doesn't really apply for web developers.
I'm trying to set the stage here.
And on the web, the whole problem reduces
to CSS scaled pixels.
So the way that works is essentially the spec provides
an angular size.
The spec defines pixels to be an angular unit.
It's a little confusing.
But you should read the article.
I think it explains it pretty well.
The basic idea though is a pixel is a certain angle.
So depending on how close or how far--
When I read it, I was trying to figure out, OK, an angle to
me is sort of this way.
But it's more the angle this way coming out of
the screen at you.
BORIS SMUS: No, it's your viewing angle actually, not
the screen.
So if the screen is in front of me, then I have a certain
viewing angle.
And what this means is basically the pixels' physical
size depends on how far the screen is from me, So this is
the spec definition.
PETE LEPAGE: Now, this gets kind of confusing and a pain
for developers.
BORIS SMUS: Sort of.
I think in practice, it's a lot simpler.
BORIS SMUS: So the way this works, the specs sets this
angular pixel.
And then a browser vendor can assign the device pixel ratio,
which scales virtual pixels into this physical pixel.
So essentially, what device pixel ratio does is it scales
every CSS pixel to the physical size.
And at that point, you basically don't even need to
know what the spec says.
PETE LEPAGE: I like that because this is sounding more
complex than I think it should be.
But with device pixel ratio, you kind of abstract yourself
from the gory details of the spec, which I go into if
you're interested.
Take a look at the article.
There's even a little diagram to illustrate that.
But yeah, basically, the pixels are scaled.
But you still have the problem of--
essentially, if you're scaling pixels, then your images are
being scaled.
And if you scale images to be large, then suddenly you have
really crappy-looking--
PETE LEPAGE: Lower quality.
BORIS SMUS: --lower quality images.
So the question then is how do you serve the
right size of image?
And there's many ways.
I mean, one solution is you just serve high DPI images
PETE LEPAGE: And that's fantastic for anybody who's on
a high-speed, dedicated internet connection who
doesn't care about their bandwidth, which is probably
not everybody.
In fact, I'd guarantee it's not everybody.
BORIS SMUS: Especially on Mobile, things are really--
well, you have slow speeds.
You have very high latency, generally, from 3G
connections, even 4G connections.
Essentially, latency isn't really changing, because it's
constrained by distance from cell tower.
So the further I am from the cell tower, the longer it's
going to take for the radio signal to come.
So it doesn't matter how fast I can get everything, it's
still going to take a little bit of time for the--
BORIS SMUS: So there's all these sort of different
constraints in mobile.
So anyway, there's multiple solutions.
You can do this in JavaScript.
And there's a whole spreadsheet that someone put
together of all the JavaScript--
PETE LEPAGE: Libraries.
BORIS SMUS: --Image solutions, OK high DPI image solutions.
And there's like at least 30.
So it's pretty impressive.
There's also CSS approaches.
So with CSS media queries, what you can do now is you can
select the proper image.
Well, essentially what you do is you set a media
query based on the--
PETE LEPAGE: It's the device pixel.
PETE LEPAGE: Device DPI or pixel--
BORIS SMUS: Device pixel ratio.
So like at the top, I'd say, hey, here's my CSS, and I
specify media query in there.
And I said device pixel ratio of between 1.0 and 1.5.
And I might do another one for 1.5 to bigger.
And that would give me the high ones.
BORIS SMUS: Exactly.
PETE LEPAGE: Now, that's only going to do images if they're
in a background, for my style sheet, or if they're maybe
specified as a background on a div or
something like that, right?
BORIS SMUS: Exactly.
So with media queries, you're constrained to CSS properties
and not content images.
So you can't set the image source with a media query.
So I can't use that for, say, hey, I want to
put an image here.
And this is my image of a newspaper article or
something like that.
BORIS SMUS: You sort of can.
I mean, you can just create a div, set the background image,
and pretend it was a content image.
And like you can even say--
PETE LEPAGE: Then I would have to generate that CSS every
time, depending on if the image is dynamic.
So I'm thinking like a news website or
something like that.
If the image is dynamic, I'm going to have to do that.
BORIS SMUS: You can still do that with JavaScript.
It's not a problem.
PETE LEPAGE: Oh yeah, that's a fair point.
That's a good point.
BORIS SMUS: I mean, you can set the background images
Anyway, so there's JavaScript, CSS.
You can do this on a server as well.

So just using the user agent, which is all we have on the
server, unfortunately, you simply just serve the high DPI
image if necessary.
So you could say, oh, this particular device, I know is a
high DPI device, so I want to serve the high DPI image.
Now, that's going to work great for a
known set of devices.
But like, say, for example, some brand new company goes
and ships the new, coolest tablet ever.
And it's got a device pixel ratio of four.
On day one, I'm probably screwed.
BORIS SMUS: Well, you're not screwed in the sense of--
PETE LEPAGE: If I use the server side, and I
don't know about it.
If you're using the server side and doing like a robust
solution, you're probably using a device database, like
what's the other one--
Device Atlas, one of those.
So there, you would just update your database.
And hopefully, they would be able to--
PETE LEPAGE: They'll provide that info.
BORIS SMUS: But you know, that's sort of theoretical.
There's definitely drawbacks.
And you'll need a custom server solution
to do this, et cetera.
So the real solution to this problem is to use things that
are built into the browser.
PETE LEPAGE: That's pretty much always a
safe thing to do.
BORIS SMUS: Because there's drawbacks
to every other approach.
And of course, the drawback here is it's not implemented
These are specs that are still sort of--
PETE LEPAGE: Would you call them release candidate?
Or are we still sort of--
BORIS SMUS: It's hard to speculate about that.
I mean, they're both specs that are somewhat in progress.
But certainly, we will have some image selection, image
set approach for both content images, like setting image
source, and for background images.
So the way with background images right now,
it's with image set.
And I talk about it in some detail in my article.
But essentially, what you're saying is you specify multiple
images, and you say what the [? x-ity ?]
is, like 1x, 1.5x, et cetera.
PETE LEPAGE: So the device pixel ratio, you
say one point whatever.
BORIS SMUS: So you provide multiple of these images.
And then the browser selects which one to load for you.
PETE LEPAGE: So the browser is smart enough to go, oh OK, we
want to grab this.
BORIS SMUS: And it's more of a guide.
So one of the drawbacks with CSS using media queries is
your device pixel ratio may be two, but you may be on a very
slow link, for example.
Then you're downloading a huge image on like your EDGE
connection, and that's a bad user experience.
So if the browser can make that call for you--
PETE LEPAGE: We definitely want the browser to do that.
BORIS SMUS: We want to do that.
So I think that's the main benefit of building it
directly into the browser.
So it's image set for CSS.
PETE LEPAGE: So that's image set.
So I would say image colon and then like provide a set?
I guess it's in the article.
BORIS SMUS: It's in the article.
But it's essentially a custom CSS function.
with its own syntax, et cetera.
And right now, it's in WebKit only, so prefix with the dash
WebKit prefix.
And it's available in Safari 6 and Chrome, I think.
the Canary.
PETE LEPAGE: So it's not available, say, on Chrome for
Android yet?
BORIS SMUS: Not yet.
But something that--
BORIS SMUS: But it will be.
PETE LEPAGE: --we hope to see coming in the near future.
BORIS SMUS: And I believe it may be--
well, it's likely to be in the next versions of both Chrome
for Android and probably Mobile Safari as well.
So we should keep an eye out for that.
Hopefully, it'll be in the next version.
BORIS SMUS: And of course, for content images, we have a
similar thing called source set.
So you have image source, and you have image source set.
PETE LEPAGE: So I'd say image source, and then I;d provide
the normal one so that legacy browers or normal browsers
will just pick that up.
But then I'd say source set--
BORIS SMUS: Source set.
PETE LEPAGE: --and that's still an attribute within the
image element, right?
BORIS SMUS: Exactly.
So it's sort of a little more complex than image set, the
CSS version.
And you can specify additional things like width and height
of the view port.
So again, this gets a little more complicated.
And in my personal opinion, both image set and source set
should have the same syntax.
They currently don't.
The other thing to know is a source set is it's not
available anywhere.
There's no implementation.
All right.
So it's cool, but we can't use it yet.
BORIS SMUS: It's cool, and we can use it with a polyfill
that I wrote.
But it's not available in any browser.
So I would say it's far less mature than image set and
likely to change more as well.
PETE LEPAGE: So the link to your
polyfill is in that article.
So if people, go have a look at that article, they can get
that link, correct?
BORIS SMUS: Correct.
So anyway, take a look at the article.
Try the polyfill.
Let me know what you think.

PETE LEPAGE: So what would you say--
I want to go, I want to make my website work best now.
What's the best thing I can do to make sure that I'm
providing the best experience?
BORIS SMUS: The best thing you can do now sort of depends on
what your target is, who your clients are, et cetera.
If you're targeting legacy browsers, you probably want to
use something less ambitious than image set and source set,
because you're just going to end up having to polyfill
everything right.
So if you're doing that, fall back to JavaScript, see if
media queries are supported, do something less ambitious.
However, if you're on the bleeding edge--
PETE LEPAGE: If you want to be sort of on the cutting edge--
BORIS SMUS: --you should probably be using image set
and source set.

Definitely image set, maybe not source set.
All right.
Well, hopefully that's a good intro to this.
This is something, I think, it's a little bit
complex right now.
It's a little bit more fun than it should be, and fun is
a subjective thing, but will become easier in the future.
This is something that I think a lot of browser vendors are
looking at and trying to figure out.
Because we really want to make sure that it's easy for you.
And as developers, it should be mostly transparent.
It should be something that you go, all right, here's my
image, and maybe I need a high DPI or low.
Actually, you know one that you didn't mention, I can't
remember if you mentioned it in your
article, but image formats.
There are some image formats that provides that.
But it doesn't stop downloading once it hits the--
So one of the things I discussed, as you mentioned,
are the progressive image formats.
So if you remember in the old days when GIFs were very
popular on the internet, you can see
this progressive loading.
So first, you get kind of a pixelly thing and then it
would refine itself instead of the cascade of loading.
So most image formats actually have this ability.
And a lot of the time, if you encode it that way, it's
actually smaller.
In some cases, it's larger.
So I talk about that.
But you might think that, hey, you can just do this and then
cut off the connection once you know that getting more
data isn't going to improve the quality of the image.
The thing with that is, especially on mobile, you
don't really want to kill connections.
The reason you don't want to kill connections is because
now you need to respawn a new connection.
And that incurs latency overhead, which can be like a
whole second in many cases.
So one workaround could be to use HTTP Range, which
essentially says get me this chunk in some image.
So what you might do is you might get the head of an
image, see the size, estimate how much data you need, get
the range, and then you don't actually
have to kill the request.
But the trouble is nobody supports Range
on the server basically.
So anyway, more details, check out the article.
PETE LEPAGE: It's a great article.
It's really worthwhile.
There's a lot of great images.
BORIS SMUS: Thanks Pete.
PETE LEPAGE: I liked it.
BORIS SMUS: Anyway, let's talk about some debugging stuff.
All right.
Well, I'm going to grab my laptop here, because I want to
talk about some of the debugging tools that Chrome
has to offer as you're building websites and web
So I'm just going to bring up Chrome.
And I want to show you a couple of the emulation tools
that are available to you.
And then I'll jump into some of the debugging tools.
So I've got Chrome up.
I'm running Chrome Beta on this.
But in addition to Chrome Beta, this is also available
on Chrome Stable, it's also available on Chrome Dev, and
there's a couple other ones.

I'm going to take a sec here.
Apparently, we're getting some flickers.
So let's try and see if I can unflicker a little bit.

All right.

So do you want to talk about--
So basically, there's multiple kinds of approaches you could
take to debugging.
The simplest probably, if you're developing a mobile app
and don't really want to deal with your Android device
plugged in via USB and doing a remote debugging, the other
approach is to emulate some mobile features that are
available in Chrome for Android but do it directly on
your desktop Chrome.
So in the dev tools, as Pete started saying, there's a
bunch of these pretty nifty features that let you
essentially constrain your Chrome browser in ways that
are similar to the constraints that you'll
find on mobile devices.
PETE LEPAGE: All right.
So we've got this up.
So I'm going to bring up the Chrome dev tools.
So I just brought them up on my new tab page.
But if you click--
BORIS SMUS: Maybe you could bump the size up.
Command Plus.
PETE LEPAGE: Command Plus.
There we go.
So I clicked on the settings guy here, and that brings up
my settings.
Now, things look a little bit weird right now because I
bumped the size up.
But there's a couple of things that pop up here that are
really interesting.
Let me come down a little bit in size.
So the first one is Override User Agent, Override Device
Metrics, and Emulate Touch Events.
So by going and turning on the Override User Agent, I can go
in, and I can choose from different user agents.
So I can specify, hey, I want to emulate a Galaxy Nexus, or
an iPhone, or an iPad.
So if I choose the emulate the Galaxy Nexus, sure enough, it
goes and sets my user agent string to be the right user
agent string.
But it also goes and turns on this Override Device Metrics
and sets my screen resolution for 720 by 1280.
So it actually says, hey, this is what my
screen resolution is.
So now, if I go down here, and I open up, sure
enough, I get the experience as I would see
it on a mobile device.
BORIS SMUS: So it's both the user agent and the device size
So as far as Google is concerned, I'm reporting as
this device, and as well, I'm also getting the right screen
So I'm kind of faking out this.
Now, there's a couple of things that I do lose here
that we don't get.
One of things we talked about earlier was the
device pixel ratio.

If there's any kind of device pixel ratio that's beyond the
normal, I'm not going to get that.
BORIS SMUS: That's actually on the horizon.
So it may be coming soon, definitely talked to some
people about it.
It seems like a very useful feature.
It's something we definitely asked for, and we've gone in
and said, hey, we think this is really important.
I had checked this morning to see if it was in Canary or
Chromium, and it wasn't there yet.
BORIS SMUS: Not yet.
PETE LEPAGE: So fingers crossed that we'll get that
kind of soon.
Because that would be really useful.
It's one of those things that I think will help.
Now, one thing that sort of caught me a couple of times, I
go to start using this, this may catch you, so in this
particular environment, my screen is set up for 1080
pixels high.
And you'll notice that when, I'm just going to bring this
up again so that we can see this--
that wasn't what I wanted.
Here we go.
There we go.
So I'm going to bring this up.
Notice my screen resolution is set for 1280.
So it's a little bit bigger than my screen.
So the browser creates that space down below.
Now, what's happening, say, for example, I want to see
this whole thing.
I want to get rid of this.
If I go close this right now, I actually--
oh, it looks like we fixed this.
No, we didn't.
BORIS SMUS: It reverted back.
It reverted back.
So now, what's happened is my screen size
goes back to normal.
BORIS SMUS: So you need to have dev tools open for the
[? screen ?] size effect.
PETE LEPAGE: So this dev tools need to stay open if you want
to do that.
Now, there's two things you can do there.
You can just sort of go and shrink these guys really,
really, really tiny.
Or the other one you can do is just undock them and move them
sort of over here.
And that's probably the easier thing to do, because now you
can actually go and--
BORIS SMUS: There's actually a third thing
you can do in Canary.
PETE LEPAGE: All right.
Let me bring up Canary.

I think I had some fun with Canary this morning in that It
wouldn't bring up the--
yeah, it won't bring up my--
BORIS SMUS: Oh, don't worry about that.
But if you click on that thing for a while and
then go like that.
Dock to right.
BORIS SMUS: So that's a pretty cool feature.
PETE LEPAGE: So that's something we can probably
expect to see in a future version of Chrome.
I think it's probably in Beta by now.
I'm not sure.
PETE LEPAGE: Well, let's find out.
BORIS SMUS: Is this Beta?
PETE LEPAGE: This is Beta.
So it is not in Beta yet.
So maybe it's in Dev.
BORIS SMUS: Yeah, could be.
It'll trickle down eventually.
It's a very useful feature.
PETE LEPAGE: It really is.
It's one of those things to be able to go and do this.
So not only do you get your user agent override so that
you can go and specify, if you do want to specify a specific
user agent, you can do that.
Because right now, they only have Android 4.0.
And do you remember, is this the Android
browser user agent?
Or is this the--

let's see--
BORIS SMUS: Good question.
I think it's the Android browser user agent.
That looks like the Android browser.
BORIS SMUS: There's no Chrome in that string.
I think there's an open request to get Chrome user
agents in there, Chrome for Android and Chrome for iOS,
but not quite yet.
PETE LEPAGE: It's not there yet.
BORIS SMUS: Either way, as you were saying, you can and paste
in anything you like.
You can even paste into Googlebot if you want to see
how Googlebot [INAUDIBLE].
That's a good point too.
So if you want to go look up the user agent strings, if you
just look up Chrome Mobile UA string, just Google that,
you'll come across the documentation.
BORIS SMUS: You should get to the developer site.
PETE LEPAGE: So let me just bring these guys up again.
So the other one that you can do is emulate touch events so
that if I want to go and turn on touch events, and I'll pop
over here and go back to
helps if I spell it right.
You'd think I'd be able to do that.
I can sort of simulate the touch events.
Now, they're not true touch events.
But they're plenty close.
BORIS SMUS: I think they're true touch events, like you
get the same touch start, touch move, and touch end as
you would in a normal event.
PETE LEPAGE: So good point.
BORIS SMUS: So a lot of sites that are designed for mobile,
like this one, might not respond to clicks directly,
because they assume that--
They're not expecting a click event.
They're expecting only the touch event.
BORIS SMUS: It might be that there's a mobile user agent,
and they just say, OK, there's only touches.
So it's useful in that case.
But of course, it's not multi-touch.
So I can't go and do any multi-touch kind of stuff
All right.
So that's the emulation stuff that you've got within Chrome.
The other one that's available is Chrome remote debugging.
And with the Chrome remote debugging, there's a video and
lots of good documentation on that.
But on my phone, I'm just going to go and open up Chrome
so that I've got something that we can go
have a look at here.

Now, before you do this, you need to have ADB installed.
Now, ADB is the Android Debugger.
And it allows you to do some port forwarding
and things like that.
Once you've got ADB installed, which is not all that hard--
it's a pretty easy process to step through--
you need to plug your phone into your laptop via USB.
And you need to turn on two things on your phone.
In the settings menu for the phone, you
need to enable debugging.
So go into the debugging settings, turn that on.
And then the second piece that you need to do is within
Chrome, you need to turn on the remote debugging.
So I've done that on this device.
And now I need to start the debugging stuff.
So generally, the stuff on the device persists, at least the
system-wide debugging does.
The Chrome one sometimes turns off for some reason.
So you might have to turn that on.
But there's a bit of like one time setup.
Hopefully, you won't need to do it all the time.
PETE LEPAGE: Once that setup's done, it's pretty easy.
I've actually created a little script to make my debugging a
little bit easier, because I don't like to remember ADB
forward TCP colon 922--
It's just more than I like to remember.
So I just got a little script that I can do, clank, debug.
So that starts my clank debugger.
BORIS SMUS: So what that actually does is this Chrome
for Android runs a server, basically.
And it runs the Chrome dev tools protocol.
And what this does, it sets up the port.
It opens the port here to make that
connectable from your desktop.
PETE LEPAGE: So now, through the USB, I've opened a TCP
port to the server on here.
BORIS SMUS: It's actually a little more complicated.
You'll see.
Anyway, we should open this up.
PETE LEPAGE: So now, I've opened it up.
And sure enough, I see my list of inspectable pages.
I can click on this.
BORIS SMUS: So you'll see it actually went to a front end
that's on the web.
The URL here is chromedevtoolsfr

So it actually serves the front end from there and
points it to here.
So a bit of indirection.
PETE LEPAGE: We've got a little bit of funky stuff.
BORIS SMUS: But it works really well.
So it's awesome.
PETE LEPAGE: So now, as I start looking at the content
that's on here, I can actually start expanding these out and
seeing what's going on in my particular page.
So I can expand this out, and say, hey, there's divs.
There's an iframe.
And as I start expanding these out, you can see that
different parts of the page start to get highlighted.
BORIS SMUS: So you have full control basically.
It's just like debugging on my desktop.
Like if I'm debugging, I can go in.
I could be like, oh, hey, I can change everything live.
I've got all the same capabilities that I would have
if I were debugging Chrome on my desktop.
I can set CSS styles.
I can set attributes, remove attributes.
I can add and remove elements, all the stuff that I'm used to
being able to do.
In fact, I can even go in and use some of the auditing and
profiling tools to be able to understand exactly where
everything is.
BORIS SMUS: It's especially important for mobile.
To understand how your network requests are coming in, it's
actually something really interesting.
One of the projects I was working on, we found a bug
that only happened when you are connected on 3G.
So we were testing this.
We were always on Wi-Fi, because that's--
generally if you can go on a fast connection.
We're great.
And we were like, all right, yeah.
And a couple of hours before we were supposed to ship this
thing, I was doing my last like sanity checks and went,
oh crap, it doesn't work with Wi-Fi turned off.
And so sure enough, it was just this little thing where
something wasn't coming in quite fast enough, and it was
just sitting there forever.
And so we made a couple of minor corrections.
But it was one of those things.
So being able to go in and see the profiling tools, the
timeline for how requests get made is a really useful tool
to be able to have.
So actually, that will be network, right?
There's network.
BORIS SMUS: Timeline is also very useful.
PETE LEPAGE: So if I reload this page, sure enough,
there's all the resources that are getting loaded for this
particular image.
And I can see how long this took.
So like the page DOM content loaded was fired here
at this blue line.
And here at this red line, the load event was fired.
BORIS SMUS: That's awesome.
Super useful.
PETE LEPAGE: Very useful.
So this is running milestone 18 of Chrome.
And it's on par with m18.
But now Chrome has moved a little forward.
So I'm running Chrome Beta on this machine.
And Chrome Beta is 21.
So Stable will be 20.
All right.
So with that, why don't me pop over and take a couple of the
questions from the moderator queue?
BORIS SMUS: Sounds good.

PETE LEPAGE: I'll grab the first one.
So the first question-- let me just reload this, make sure
we've got the latest stuff.

What's your opinion on using mobile framework such as
jQuery Mobile?
BORIS SMUS: Good question.
PETE LEPAGE: It is a good question.
So I think, my opinion, using stuff like that has its place.
And I've used jQuery Mobile for a couple projects.
I thought it was a neat sort of place to start and
experiment with.
It doesn't necessarily work for every single project.
And it does provide a few headaches here and there, if
you want to do things that jQuery Mobile doesn't support
or sort of falls outside the box.
What's your view on it?
BORIS SMUS: I kind of agree.
I think it's great for sort of these apps that are very
So you have like hierarchical sets of views that are all
kind of similar and maybe text heavy.
PETE LEPAGE: I want to go look something up.
I want to flow through something,
something like that.
BORIS SMUS: And you can break out of the mold with plug-ins
that have a plug-in framework.
So if you want to do something a little bit outside of that
framework, it's fine.
But if you're doing like a complex app with its own kind
of UI, maybe there's some drawing app or something where
it's a lot of interaction that's not really common to
the sorts of apps that it's designed for, I would say
don't use it and like look to something else.
Maybe look to a framework like Sencha or something like that.
Or roll your own.
Because ultimately, you might need to go there.
PETE LEPAGE: Do you want to read off the next question?
BORIS SMUS: OK, let's see.
Any way to launch Chrome after clicking links
in any apps on iPad?
It launches Safari even after updating Gmail?
So basically, you can--
as an iOS app developer, you can write an app that will
check if Chrome is installed and launch
Chrome instead of Safari.
That said, it's up to the app developer and not the user.
So if I, the user, say if I want Chrome to be launched
every time any link opens, I'm out of luck.
iOS doesn't provide that sort of flexibility.
So about Gmail specifically, they have their own agendas.
PETE LEPAGE: They may hopefully.
That's actually a good point.
We'll go send an email to the Gmail team.
But I know that the Google+ team just updated their
Google+ app.
If Chrome is installed, it'll open links in Chrome on iOS if
it's installed.
So it's going to be a matter of getting developers to go
and start doing that.
If you have an app or use an app, go ask your developer to
enable that feature.
That will be a really nice thing to have.
All right.
Next question?
Next question.
BORIS SMUS: All right.
So there's a question about using a master key to secure
saved passwords in Chrome for PC.

So I think this is something about key chaining, probably--
PETE LEPAGE: What's the specific question say?
BORIS SMUS: What about a master key to secure the saved
passwords in Chrome for PC?
So I would say maybe if--
I am not sure I quite understand the question, but
if you can go provide a little bit more detail in there,
we'll take a look at that this afternoon and try and put an
answer in there if we can understand that.
BORIS SMUS: There was one more.
PETE LEPAGE: All right.
One more question.
I think we'll take this as our last question and
then wrap it up.
BORIS SMUS: So workarounds to--
this is not really Mobile-related, but I think we
can probably talk a little bit about.
Workarounds to execute dynamically generated scripts
in iframes in Manifest 2.
So this is an app or extension question.
PETE LEPAGE: So I think with that, the one piece that I
would say to go have a look at is the sandboxed iframe stuff.
Because with sandbox iframes--
with Manifest version 2, they implement
Content Security Policy.
Content Security Policy is a piece that helps to protect
you from cross-site scripting and other security
And it restricts some of the things that can happen.
With a sandboxed iframe, you can do a lot of not so safe
stuff, but it's sandboxed and can't get outside
that sandbox generally.
BORIS SMUS: So you can do eval in a sandboxed iframe?
PETE LEPAGE: You know, I can't remember the exact list of
things, but I think you may be able to do that.
So it's worth having a look at the sandboxed iframe.
And the sandboxed iframe is actually a larger piece that
doesn't just fit into Chrome apps and extensions, but it's
something that's coming to the web in general.
And if you're doing it on the web in general, you can also
set your own custom Content Security Policy.
PETE LEPAGE: Absolutely.
And you can modify that as well.
BORIS SMUS: So I guess Manifest 2 sort of suggests
that you're doing it in Chrome apps or extensions.
PETE LEPAGE: Good point.
BORIS SMUS: All right.
I think that's all the time we have.
So thanks guys for joining us.
PETE LEPAGE: Thank you very much.
And we'll be doing these more regularly.
We'd love to hear your feedback.
Let us know either through the comments or
anything like that.
So with that, thanks very much.
And we'll chat soon.
Bye bye.