Hookup android_webview scroll offset delegation to Java side.

Hookup android_webview scroll offset delegation to Java side.

This connects the scroll offset that is delegated from the
CC all the way up to the Java android.view.View class.

BUG=b/6029133
TEST=AndroidWebViewTest

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207614

[joth, 2013-06-08 00:16:49]

moving discussion from https://chromiumcodereview.appspot.com/15002007/ over
here, as it's far more relevant to this patch.



ISTM ideally we'd use the webview.computeScroll() to go to cc and get it to
update the scroll positions so far as it has any, so that our BeginFrame can
then be sure not to cause scroll updates. This may or may not tie in well with
the bigger BeginFrame changes plan - maybe useful for you to sync with Sami on
that.


in the grand scheme - if we did end up with some JNI in the draw functor purely
to deal with JS initiated scrolling we'll live, certainly in the context of
doing initial bring up of all this.

because functor happens after full traversal, if scroll changes do come up from
cc during the functor / BeginFrame (needs confirmation) , then _in terms of
scroll correctness_ it's fine to update the java side right away, as the child
views have already drawn.





my working conceptual model is:-

prepareDrawGl() {
  gl_draw_pending_ = true;
}

drawGl() {
  compositor->draw();
  updateScrollFromJava();
  in_draw_gl_ = false;
}

handleScrollChangeFromJava() {
  if (!gl_draw_pending_)
    updateScrollFromJava();
}

updateScrollFromJava() {
  scroll_offet_ = getFromJava();
  if scroll_offet_ != old
    tellCcScrollChanged();
}
 
// cc scroll delegate methods
setScroll(value) {  
  tellJava(value);  // may trigger handleScrollChangeFromJava()
}

value getScrollForCc() {
  return scroll_offet_;
}

https://chromiumcodereview.appspot.com/16255010/diff/9001/android_webview/jav...
File
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java
(right):

https://chromiumcodereview.appspot.com/16255010/diff/9001/android_webview/jav...
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java:27:
public void onInProcessRendererScrollChanged(int xPix, int yPix) {
nit: "InProcessRender" seems an unnecessary naming scheme to have to introduce
into the java code. something along the lines of onNativeScrollChanged... ?

[mkosiba (inactive), 2013-06-11 15:31:38]

> moving discussion from https://chromiumcodereview.appspot.com/15002007/ over
> here, as it's far more relevant to this patch.
> 
> 
> 
> ISTM ideally we'd use the webview.computeScroll() to go to cc and get it to

nope. CC will not be driving the root layer scroll offset 'on it's own'.
The only cases where we expect CC to update the root layer scroll offset are:
  - touch processing (which is intitiated from aw/)
  - renderer main -> impl thread commits (which happen 'spontaneously' via
    a PostTask from the main thread)
  - fling animations, as I previously mentioned, should be moved to
    the Java layer, so we can ignore these.

> update the scroll positions so far as it has any, so that our BeginFrame can
> then be sure not to cause scroll updates. This may or may not tie in well with
> the bigger BeginFrame changes plan - maybe useful for you to sync with Sami on
> that.

BTW. I spoke to Sami a bit and he suggested that if we want to 'snapshot' the
state of CC at a particular time we might want to look at PrepareToDraw.

As far as what could happen on BeginFrame - Sami said that shouldn't cause
a commit.

> 
> 
> in the grand scheme - if we did end up with some JNI in the draw functor
purely
> to deal with JS initiated scrolling we'll live, certainly in the context of
> doing initial bring up of all this.

This should not be possible - JS-initiated scrolling can only happen between
the onDraw and the functor call.

> 
> because functor happens after full traversal, if scroll changes do come up
from
> cc during the functor / BeginFrame (needs confirmation) , then _in terms of
> scroll correctness_ it's fine to update the java side right away, as the child
> views have already drawn.
> 
> 
> 
> 
> 
> my working conceptual model is:-
> 
> prepareDrawGl() {
>   gl_draw_pending_ = true;
> }
> 
> drawGl() {
>   compositor->draw();
>   updateScrollFromJava();
>   in_draw_gl_ = false;
> }
> 
> handleScrollChangeFromJava() {
>   if (!gl_draw_pending_)
>     updateScrollFromJava();
> }
> 
> updateScrollFromJava() {
>   scroll_offet_ = getFromJava();
>   if scroll_offet_ != old
>     tellCcScrollChanged();
> }
>  
> // cc scroll delegate methods
> setScroll(value) {  
>   tellJava(value);  // may trigger handleScrollChangeFromJava()
> }
> 
> value getScrollForCc() {
>   return scroll_offet_;
> }
> 

Ok, I get this. The question I'm asking is what does this buy us compared to
my proposal?

>
https://chromiumcodereview.appspot.com/16255010/diff/9001/android_webview/jav...
> File
>
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java
> (right):
> 
>
https://chromiumcodereview.appspot.com/16255010/diff/9001/android_webview/jav...
>
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java:27:
> public void onInProcessRendererScrollChanged(int xPix, int yPix) {
> nit: "InProcessRender" seems an unnecessary naming scheme to have to introduce
> into the java code. something along the lines of onNativeScrollChanged... ?

[mkosiba (inactive), 2013-06-14 18:06:43]

This is an updated version of the scrolling CL.

Unfortunately BeginFrame results in a pending->active tree promotion, which
results in a root layer scroll offset set. That in turn makes it impossible to
trick the CC into drawing with the scroll_at_start_of_frame_ offset.

[joth, 2013-06-18 03:19:50]

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/b...
File android_webview/browser/browser_view_renderer.h (right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/b...
android_webview/browser/browser_view_renderer.h:94: const gfx::Vector2d&
scroll_pix,
is _pix a standard convention? If not, it doesn't seem to add much (as we have
numerous types of pixel) - the fact it's non-float suggests me it's physical px.

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/b...
android_webview/browser/browser_view_renderer.h:111: // physical pixels.
physical pixels? these are normally scalar, not floats. (AIUI)

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/i...
File android_webview/browser/in_process_view_renderer.cc (left):

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/i...
android_webview/browser/in_process_view_renderer.cc:581: 
mistake?

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/i...
File android_webview/browser/in_process_view_renderer.h (right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/i...
android_webview/browser/in_process_view_renderer.h:49: virtual void
ScrollTo(gfx::Vector2dF new_value_css) OVERRIDE;
ah ha! over here you call it CSS pixels :)

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
File android_webview/java/src/org/chromium/android_webview/AwContents.java
(right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
android_webview/java/src/org/chromium/android_webview/AwContents.java:415:
mScrollOffsetManager = new AwScrollOffsetManager(new
AwScrollOffsetManagerDelegate(),
is this thing intended to be injectable now (this patch) / later?

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
File
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java
(right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java:29:
public void scrollContainerViewTo(int xCss, int yCss) {
don't CSS pixels normally travel in a float?

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java:31:
mNativeScrollYPix = (int) (yCss * mDIPScale);
maybe it's not difference either way, but I was hoping to keep CSS pixels as an
internal concept to lower (native) layers and keep java in framework units. Is
there specific need for this to be css here? I guess this maybe water under the
bridge as ContentViewCore is already boshing values about in CSS units?

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java:35:
mDelegate.getContainerViewScrollYPix());
the logic in this class is verging on so simple it is adding more mental
overhead having the extra class and abstractions than it helps. Writing tests
for it as part of AwContents would be a mess though, it's true

https://codereview.chromium.org/16255010/diff/17001/android_webview/javatests...
File
android_webview/javatests/src/org/chromium/android_webview/test/AndroidScrollIntegrationTest.java
(right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/javatests...
android_webview/javatests/src/org/chromium/android_webview/test/AndroidScrollIntegrationTest.java:163:
"window.scrollTo(" + targetScrollXCss + "," + targetScrollYCss + ");");
maybe easier as:
String.format("window.scrollTo(%d, %d);", targetScrollXCs, targetScrollYCss);

(check the format string - I haven't read the spec.)

https://codereview.chromium.org/16255010/diff/17001/ui/gfx/vector2d_f.h
File ui/gfx/vector2d_f.h (right):

https://codereview.chromium.org/16255010/diff/17001/ui/gfx/vector2d_f.h#newco...
ui/gfx/vector2d_f.h:74: return lhs.x() != rhs.x() || lhs.y() != rhs.y();
return !(operator==(lhs, rhs));

I'm sure there's a great reason these aren't member functions, but it escapes me
now

[mkosiba (inactive), 2013-06-18 18:09:24]

ok, new version up, PTAL

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/b...
File android_webview/browser/browser_view_renderer.h (right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/b...
android_webview/browser/browser_view_renderer.h:94: const gfx::Vector2d&
scroll_pix,
On 2013/06/18 03:19:50, joth wrote:
> is _pix a standard convention? If not, it doesn't seem to add much (as we have
> numerous types of pixel) - the fact it's non-float suggests me it's physical
px.

it seems to be the convention used in RenderCorrdinates. Now I'm thinking it may
be sufficient to call out the stuff that's in CSS pixels, and assume everything
else in the renderer is in physical pixels.

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/b...
android_webview/browser/browser_view_renderer.h:111: // physical pixels.
On 2013/06/18 03:19:50, joth wrote:
> physical pixels? these are normally scalar, not floats. (AIUI)

Done.

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/i...
File android_webview/browser/in_process_view_renderer.cc (left):

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/i...
android_webview/browser/in_process_view_renderer.cc:581: 
On 2013/06/18 03:19:50, joth wrote:
> mistake?

yes

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/i...
File android_webview/browser/in_process_view_renderer.h (right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/browser/i...
android_webview/browser/in_process_view_renderer.h:49: virtual void
ScrollTo(gfx::Vector2dF new_value_css) OVERRIDE;
On 2013/06/18 03:19:50, joth wrote:
> ah ha! over here you call it CSS pixels :)

see? making it explicit is paying off already :)

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
File android_webview/java/src/org/chromium/android_webview/AwContents.java
(right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
android_webview/java/src/org/chromium/android_webview/AwContents.java:415:
mScrollOffsetManager = new AwScrollOffsetManager(new
AwScrollOffsetManagerDelegate(),
On 2013/06/18 03:19:50, joth wrote:
> is this thing intended to be injectable now (this patch) / later?

maybe later, why?

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
File
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java
(right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java:29:
public void scrollContainerViewTo(int xCss, int yCss) {
On 2013/06/18 03:19:50, joth wrote:
> don't CSS pixels normally travel in a float?

yes, they should.

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java:31:
mNativeScrollYPix = (int) (yCss * mDIPScale);
On 2013/06/18 03:19:50, joth wrote:
> maybe it's not difference either way, but I was hoping to keep CSS pixels as
an
> internal concept to lower (native) layers and keep java in framework units. Is
> there specific need for this to be css here? I guess this maybe water under
the
> bridge as ContentViewCore is already boshing values about in CSS units?


I don't think there is a really compelling reason. The alternative was to push
the DIP scale into the in_process_view_renderer.cc, so I thought this would be
simpler, but I can see the benefits of sticking to the framework pixel units in
Java.

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java:35:
mDelegate.getContainerViewScrollYPix());
On 2013/06/18 03:19:50, joth wrote:
> the logic in this class is verging on so simple it is adding more mental
> overhead having the extra class and abstractions than it helps. Writing tests
> for it as part of AwContents would be a mess though, it's true

the main reason I opted to make this a separate class is that I expect I'll have
to add some fun code here in the future (to correctly support pinch-zoomable
wrap-content webviews we'll have to ensure the correct scroll offset ourselves
:/)

https://codereview.chromium.org/16255010/diff/17001/android_webview/javatests...
File
android_webview/javatests/src/org/chromium/android_webview/test/AndroidScrollIntegrationTest.java
(right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/javatests...
android_webview/javatests/src/org/chromium/android_webview/test/AndroidScrollIntegrationTest.java:163:
"window.scrollTo(" + targetScrollXCss + "," + targetScrollYCss + ");");
On 2013/06/18 03:19:50, joth wrote:
> maybe easier as:
> String.format("window.scrollTo(%d, %d);", targetScrollXCs, targetScrollYCss);
> 
> (check the format string - I haven't read the spec.)

Done.

https://codereview.chromium.org/16255010/diff/17001/ui/gfx/vector2d_f.h
File ui/gfx/vector2d_f.h (right):

https://codereview.chromium.org/16255010/diff/17001/ui/gfx/vector2d_f.h#newco...
ui/gfx/vector2d_f.h:74: return lhs.x() != rhs.x() || lhs.y() != rhs.y();
On 2013/06/18 03:19:50, joth wrote:
> return !(operator==(lhs, rhs));
> 

Done.

> I'm sure there's a great reason these aren't member functions, but it escapes
me
> now

I think it has to do with namespaces and resolution order, but I might be wrong.

[joth, 2013-06-19 05:34:45]

basically lgtm, thanks!

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
File android_webview/java/src/org/chromium/android_webview/AwContents.java
(right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
android_webview/java/src/org/chromium/android_webview/AwContents.java:415:
mScrollOffsetManager = new AwScrollOffsetManager(new
AwScrollOffsetManagerDelegate(),
On 2013/06/18 18:09:25, mkosiba wrote:
> On 2013/06/18 03:19:50, joth wrote:
> > is this thing intended to be injectable now (this patch) / later?
> 
> maybe later, why?

no problem, just wanted to understand the separations

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
File
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java
(right):

https://codereview.chromium.org/16255010/diff/17001/android_webview/java/src/...
android_webview/java/src/org/chromium/android_webview/AwScrollOffsetManager.java:31:
mNativeScrollYPix = (int) (yCss * mDIPScale);
On 2013/06/18 18:09:25, mkosiba wrote:
> On 2013/06/18 03:19:50, joth wrote:
> > maybe it's not difference either way, but I was hoping to keep CSS pixels as
> an
> > internal concept to lower (native) layers and keep java in framework units.
Is
> > there specific need for this to be css here? I guess this maybe water under
> the
> > bridge as ContentViewCore is already boshing values about in CSS units?
> 
> 
> I don't think there is a really compelling reason. The alternative was to push
> the DIP scale into the in_process_view_renderer.cc, so I thought this would be
> simpler, but I can see the benefits of sticking to the framework pixel units
in
> Java.

I think in_process_view_renderer.cc will need to know these conversions
whatever: see  https://code.google.com/p/chromium/issues/detail?id=224003 and
also my TODO in InProcessViewRenderer::RenderSW
https://code.google.com/p/chromium/codesearch#chromium/src/android_webview/br...

so I if it does work out just as well to do this conversion there too, I'd
rather keep that in the one place -- all else being equal etc etc.

https://codereview.chromium.org/16255010/diff/26001/android_webview/browser/b...
File android_webview/browser/browser_view_renderer.h (right):

https://codereview.chromium.org/16255010/diff/26001/android_webview/browser/b...
android_webview/browser/browser_view_renderer.h:111: virtual void
ScrollTo(gfx::Vector2d new_value_pix) = 0;
ok you dropped _pix from scroll in OnDraw above, but added it here now. Should
be in both then?

https://codereview.chromium.org/16255010/diff/26001/android_webview/browser/i...
File android_webview/browser/in_process_view_renderer.cc (right):

https://codereview.chromium.org/16255010/diff/26001/android_webview/browser/i...
android_webview/browser/in_process_view_renderer.cc:653: 
nit: spurious \n

https://codereview.chromium.org/16255010/diff/26001/android_webview/browser/i...
android_webview/browser/in_process_view_renderer.cc:669: bool value_changed =
scroll_offset_css_ != new_value_css;
nit: local var really needed?

https://codereview.chromium.org/16255010/diff/26001/android_webview/java/src/...
File android_webview/java/src/org/chromium/android_webview/AwContents.java
(right):

https://codereview.chromium.org/16255010/diff/26001/android_webview/java/src/...
android_webview/java/src/org/chromium/android_webview/AwContents.java:450:
nativeSetDipScale(mNativeAwContents, mDIPScale);
interesting - I thought we already had this in the view renderer, but looks like
it was only via FrameMetaData and so yeah this seems the appropriate when to
connect it through.

https://codereview.chromium.org/16255010/diff/26001/ui/gfx/vector2d_f.h
File ui/gfx/vector2d_f.h (right):

https://codereview.chromium.org/16255010/diff/26001/ui/gfx/vector2d_f.h#newco...
ui/gfx/vector2d_f.h:74: return lhs.x() != rhs.x() || lhs.y() != rhs.y();
maybe missed my other suggestion:
return !(operator== (a, b));

[mkosiba (inactive), 2013-06-19 11:12:19]

https://codereview.chromium.org/16255010/diff/26001/android_webview/browser/b...
File android_webview/browser/browser_view_renderer.h (right):

https://codereview.chromium.org/16255010/diff/26001/android_webview/browser/b...
android_webview/browser/browser_view_renderer.h:111: virtual void
ScrollTo(gfx::Vector2d new_value_pix) = 0;
On 2013/06/19 05:34:45, joth wrote:
> ok you dropped _pix from scroll in OnDraw above, but added it here now. Should
> be in both then?

I'm not sure why I changed it to that. moving it back to new_value.

https://codereview.chromium.org/16255010/diff/26001/android_webview/browser/i...
File android_webview/browser/in_process_view_renderer.cc (right):

https://codereview.chromium.org/16255010/diff/26001/android_webview/browser/i...
android_webview/browser/in_process_view_renderer.cc:653: 
On 2013/06/19 05:34:45, joth wrote:
> nit: spurious \n

Done.

https://codereview.chromium.org/16255010/diff/26001/android_webview/browser/i...
android_webview/browser/in_process_view_renderer.cc:669: bool value_changed =
scroll_offset_css_ != new_value_css;
On 2013/06/19 05:34:45, joth wrote:
> nit: local var really needed?

no, I forgot to remove it while restructuring the code.

https://codereview.chromium.org/16255010/diff/26001/ui/gfx/vector2d_f.h
File ui/gfx/vector2d_f.h (right):

https://codereview.chromium.org/16255010/diff/26001/ui/gfx/vector2d_f.h#newco...
ui/gfx/vector2d_f.h:74: return lhs.x() != rhs.x() || lhs.y() != rhs.y();
On 2013/06/19 05:34:45, joth wrote:
> maybe missed my other suggestion:
> return !(operator== (a, b));

ah.. sorry.. yes. completely missed that

[commit-bot: I haz the power, 2013-06-19 14:32:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mkosiba@chromium.org/16255010/49001

[commit-bot: I haz the power, 2013-06-19 14:42:46]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[commit-bot: I haz the power, 2013-06-19 16:19:31]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mkosiba@chromium.org/16255010/56001

[commit-bot: I haz the power, 2013-06-19 16:25:07]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[commit-bot: I haz the power, 2013-06-19 16:45:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mkosiba@chromium.org/16255010/56001

[commit-bot: I haz the power, 2013-06-19 16:59:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mkosiba@chromium.org/16255010/56001

[mkosiba (inactive), 2013-06-19 17:03:35]

@msw, @kbr - OWNERS rubber stamp please?

[msw, 2013-06-19 17:14:30]

See ui/gfx/OWNERS, my ownership is for RenderText files.
danakj is probably the correct OWNER for ui/gfx/vector2d_f.h

[danakj, 2013-06-19 17:18:59]

ui/gfx/vector2df LGTM w/ nit

https://codereview.chromium.org/16255010/diff/56001/ui/gfx/vector2d_f.h
File ui/gfx/vector2d_f.h (right):

https://codereview.chromium.org/16255010/diff/56001/ui/gfx/vector2d_f.h#newco...
ui/gfx/vector2d_f.h:74: return !(operator==(lhs, rhs));
nit: return !(lhs == rhs);

[mkosiba (inactive), 2013-06-19 17:32:30]

On 2013/06/19 17:14:30, msw wrote:
> See ui/gfx/OWNERS, my ownership is for RenderText files.
> danakj is probably the correct OWNER for ui/gfx/vector2d_f.h

ah, sorry, my bad. I lazily used git cl upload suggestions.

[Ken Russell (switch to Gerrit), 2013-06-19 19:45:24]

ui/gfx LGTM FWIW

[commit-bot: I haz the power, 2013-06-20 01:43:12]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mkosiba@chromium.org/16255010/74001

[commit-bot: I haz the power, 2013-06-20 03:25:28]

Sorry for I got bad news for ya.
Compile failed with a clobber build on android_dbg.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2013-06-20 13:18:22]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mkosiba@chromium.org/16255010/80001

[commit-bot: I haz the power, 2013-06-20 14:44:22]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_clan...

[commit-bot: I haz the power, 2013-06-20 14:51:14]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mkosiba@chromium.org/16255010/80001

[commit-bot: I haz the power, 2013-06-20 22:40:32]

Change committed as 207614