Modify gesture event types for WebView-tag scroll bubbling.

Modify gesture event types for WebView-tag scroll bubbling.

This CL:

(1) Adds a field |resendingPluginId|to allow unconsumed
scroll events to be marked as "resent". This will allow
asynchronous processing of scrolls between embedder/guest
for BrowserTag WebView.

(2) Forwards GestureFlingStart to the target node so that a
guest can properly determine the begin and end of a gesture
scroll. Previously the guest might receive two or more
GestureScrollStart events in succession, causing debug-builds
to fail on DCHECKs. GestureFlingStart conversions are updated
to propagate velocities, as receiving a GestureFlingStart
with zero velocity will trigger errors.

In a future CL it may be possible to avoid creating fling
curves in the embedder that target a guest---these flings
will instead be created in the guest. This will decrease IPC
traffic, and presumably decrease jitter in the guest's fling.

(3) Add plumbing so GestureScrollUpdate's |inertial| field be
properly converted between WebGestureEvent, GestureEvent and
PlatformGestureEvent. This is required so the guest can
filter GestureScrollUpdates that are generated by fling
curves, as these are generated outside the GestureScrollBegin
and GestureScrollEnd-GestureFlingStart boundaries.

Note: when WebView-tag transitions to using OOPIF instead of
BrowserPlugin, all of this can be removed (though I would
recommend still allowing plugins to process GestureFlingStart)

This CL must land before
https://codereview.chromium.org/1308273003/

BUG=491940
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=202448

[wjmaclean, 2015-09-11 13:35:37]

wjmaclean@chromium.org changed reviewers:
+ rbyers@google.com

[wjmaclean, 2015-09-11 13:36:06]

wjmaclean@chromium.org changed reviewers:
+ rbyers@chromium.org
- rbyers@google.com

[wjmaclean, 2015-09-11 15:18:22]

rbyers@ please take a look? Mostly plumbing ...

[tdresser, 2015-09-11 15:25:20]

tdresser@chromium.org changed reviewers:
+ tdresser@chromium.org

[tdresser, 2015-09-11 15:25:21]

https://codereview.chromium.org/1308313005/diff/80001/Source/platform/Platfor...
File Source/platform/PlatformGestureEvent.h (right):

https://codereview.chromium.org/1308313005/diff/80001/Source/platform/Platfor...
Source/platform/PlatformGestureEvent.h:125: {
Can we keep this consistent with the other accessors, which assert that the type
is correct?

https://codereview.chromium.org/1308313005/diff/80001/Source/platform/Platfor...
Source/platform/PlatformGestureEvent.h:197: int m_resendSource;
Why is this an int?

https://codereview.chromium.org/1308313005/diff/80001/Source/web/WebViewImpl.cpp
File Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1308313005/diff/80001/Source/web/WebViewImpl....
Source/web/WebViewImpl.cpp:755: if (event.type ==
WebInputEvent::GestureFlingStart)
Is the indentation here a little off?

[wjmaclean, 2015-09-11 15:31:01]

https://codereview.chromium.org/1308313005/diff/80001/Source/platform/Platfor...
File Source/platform/PlatformGestureEvent.h (right):

https://codereview.chromium.org/1308313005/diff/80001/Source/platform/Platfor...
Source/platform/PlatformGestureEvent.h:125: {
On 2015/09/11 15:25:20, tdresser wrote:
> Can we keep this consistent with the other accessors, which assert that the
type
> is correct?

Sure, I'll add an ASSERT in the next version of the patch.

https://codereview.chromium.org/1308313005/diff/80001/Source/platform/Platfor...
Source/platform/PlatformGestureEvent.h:197: int m_resendSource;
On 2015/09/11 15:25:20, tdresser wrote:
> Why is this an int?

Since there can be multiple BrowserPlugins in a page, the guest will put the
BrowserPlugin's unique ID into the resendSource field, just to check that it
makes it's way back to the right place in the embedder.

https://codereview.chromium.org/1308313005/diff/80001/Source/web/WebViewImpl.cpp
File Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1308313005/diff/80001/Source/web/WebViewImpl....
Source/web/WebViewImpl.cpp:755: if (event.type ==
WebInputEvent::GestureFlingStart)
On 2015/09/11 15:25:20, tdresser wrote:
> Is the indentation here a little off?

Ooops, you're right ... will fix this in the next version.

[tdresser, 2015-09-11 15:34:10]

https://codereview.chromium.org/1308313005/diff/80001/Source/platform/Platfor...
File Source/platform/PlatformGestureEvent.h (right):

https://codereview.chromium.org/1308313005/diff/80001/Source/platform/Platfor...
Source/platform/PlatformGestureEvent.h:197: int m_resendSource;
On 2015/09/11 15:31:01, wjmaclean wrote:
> On 2015/09/11 15:25:20, tdresser wrote:
> > Why is this an int?
> 
> Since there can be multiple BrowserPlugins in a page, the guest will put the
> BrowserPlugin's unique ID into the resendSource field, just to check that it
> makes it's way back to the right place in the embedder.

Makes sense. Can we clarify the meaning with a better member name (or at least a
comment?).

Maybe something like resendingPluginId?

[wjmaclean, 2015-09-11 15:37:14]

On 2015/09/11 15:34:10, tdresser wrote:
> 
> Makes sense. Can we clarify the meaning with a better member name (or at least
a
> comment?).
> 
> Maybe something like resendingPluginId?

I'm ok, though do we want 'plugin' in the name? Could any other use be forseen?
If not, I'm good with the name you suggest.

[wjmaclean, 2015-09-11 15:37:23]

https://codereview.chromium.org/1308313005/diff/80001/Source/web/WebViewImpl.cpp
File Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1308313005/diff/80001/Source/web/WebViewImpl....
Source/web/WebViewImpl.cpp:755: if (event.type ==
WebInputEvent::GestureFlingStart)
On 2015/09/11 15:31:01, wjmaclean wrote:
> On 2015/09/11 15:25:20, tdresser wrote:
> > Is the indentation here a little off?
> 
> Ooops, you're right ... will fix this in the next version.

Actually, I don't think this should even be here ... removing ...

[tdresser, 2015-09-11 15:40:07]

On 2015/09/11 15:37:14, wjmaclean wrote:
> On 2015/09/11 15:34:10, tdresser wrote:
> > 
> > Makes sense. Can we clarify the meaning with a better member name (or at
least
> a
> > comment?).
> > 
> > Maybe something like resendingPluginId?
> 
> I'm ok, though do we want 'plugin' in the name? Could any other use be
forseen?
> If not, I'm good with the name you suggest.

If we were going to use it for anything else, we'd have to worry about ID
collisions between plugin ids and other ids.
I think it makes sense to be explicit now, and if we want to use it for other
things in the future, we can do a find and replace.

[wjmaclean, 2015-09-11 15:41:06]

On 2015/09/11 15:40:07, tdresser wrote:
> On 2015/09/11 15:37:14, wjmaclean wrote:
> > On 2015/09/11 15:34:10, tdresser wrote:
> > > 
> > > Makes sense. Can we clarify the meaning with a better member name (or at
> least
> > a
> > > comment?).
> > > 
> > > Maybe something like resendingPluginId?
> > 
> > I'm ok, though do we want 'plugin' in the name? Could any other use be
> forseen?
> > If not, I'm good with the name you suggest.
> 
> If we were going to use it for anything else, we'd have to worry about ID
> collisions between plugin ids and other ids.
> I think it makes sense to be explicit now, and if we want to use it for other
> things in the future, we can do a find and replace.

Sure, sounds good ... name-change coming up ...

[tdresser, 2015-09-15 12:37:19]

The CQ bit was checked by tdresser@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-09-15 12:37:29]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308313005/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308313005/120001

[commit-bot: I haz the power, 2015-09-15 13:06:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-15 13:06:56]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[tdresser, 2015-09-15 13:13:08]

Let's use -1 instead of 0 for an event which isn't resent. I'm worried we might
get confused if we have a plugin of id 0. (And I think it's a bit clearer that
the event isn't resent).

It might make sense to define a constant named such that it indicates that the
event isn't resent.

https://codereview.chromium.org/1308313005/diff/120001/Source/core/events/Ges...
File Source/core/events/GestureEvent.cpp (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/core/events/Ges...
Source/core/events/GestureEvent.cpp:99: , m_resendingPluginId(0)
Let's default m_resendingPluginId to -1, to avoid confusion with a plugin of id
0.

https://codereview.chromium.org/1308313005/diff/120001/Source/core/events/Whe...
File Source/core/events/WheelEvent.cpp (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/core/events/Whe...
Source/core/events/WheelEvent.cpp:54: , m_resendingPluginId(0)
Let's default m_resendingPluginId to -1, to avoid confusion with a plugin of id
0.

https://codereview.chromium.org/1308313005/diff/120001/Source/core/events/Whe...
Source/core/events/WheelEvent.cpp:68: , m_resendingPluginId(0)
ditto

https://codereview.chromium.org/1308313005/diff/120001/Source/platform/Platfo...
File Source/platform/PlatformGestureEvent.h (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/platform/Platfo...
Source/platform/PlatformGestureEvent.h:126: ASSERT(m_type ==
PlatformEvent::GestureScrollUpdate);
In WebInputEventConversion, we populate the plugin id for GestureScrollBegin and
GestureScrollEnd as well. Why are we inconsistent?

https://codereview.chromium.org/1308313005/diff/120001/Source/platform/Platfo...
Source/platform/PlatformGestureEvent.h:130: return 0;
Let's return -1 here.

https://codereview.chromium.org/1308313005/diff/120001/Source/platform/Platfo...
File Source/platform/PlatformWheelEvent.h (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/platform/Platfo...
Source/platform/PlatformWheelEvent.h:67: , m_resendingPluginId(0)
-1

https://codereview.chromium.org/1308313005/diff/120001/Source/web/WebViewImpl...
File Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/web/WebViewImpl...
Source/web/WebViewImpl.cpp:690: 
Remove space.

https://codereview.chromium.org/1308313005/diff/120001/Source/web/WebViewImpl...
Source/web/WebViewImpl.cpp:715:
mainFrameImpl()->frame()->eventHandler().handleGestureScrollEvent(platformEvent);
Why do we need to explicitly repost the fling? Can it take the same path that
other gestures are taking?

https://codereview.chromium.org/1308313005/diff/120001/Source/web/WebViewImpl...
Source/web/WebViewImpl.cpp:1874: endScrollEvent.setScrollGestureData(0, 0, 0, 0,
true, false, 0);
-1

We might want to define a constant for this, indicating that this means that the
event is not reposted.

https://codereview.chromium.org/1308313005/diff/120001/Source/web/tests/Visua...
File Source/web/tests/VisualViewportTest.cpp (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/web/tests/Visua...
Source/web/tests/VisualViewportTest.cpp:1616: gsu.setScrollGestureData(-50, -60,
1, 1, false, 0, false);
-1

https://codereview.chromium.org/1308313005/diff/120001/Source/web/tests/WebIn...
File Source/web/tests/WebInputEventConversionTest.cpp (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/web/tests/WebIn...
Source/web/tests/WebInputEventConversionTest.cpp:437:
platformGestureEvent.setScrollGestureData(30, 32, 40, 42, true, 0, true);
-1

https://codereview.chromium.org/1308313005/diff/120001/Source/web/tests/WebIn...
Source/web/tests/WebInputEventConversionTest.cpp:877: true, false, false, false,
0, true, 0, true, Event::RailsModeHorizontal);
-1

https://codereview.chromium.org/1308313005/diff/120001/public/web/WebInputEve...
File public/web/WebInputEvent.h (right):

https://codereview.chromium.org/1308313005/diff/120001/public/web/WebInputEve...
public/web/WebInputEvent.h:417: , resendingPluginId(0)
-1

https://codereview.chromium.org/1308313005/diff/120001/public/web/WebInputEve...
public/web/WebInputEvent.h:521: , resendingPluginId(0)
-1

[wjmaclean, 2015-09-15 15:02:48]

https://codereview.chromium.org/1308313005/diff/120001/Source/core/events/Ges...
File Source/core/events/GestureEvent.cpp (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/core/events/Ges...
Source/core/events/GestureEvent.cpp:99: , m_resendingPluginId(0)
On 2015/09/15 13:13:07, tdresser wrote:
> Let's default m_resendingPluginId to -1, to avoid confusion with a plugin of
id
> 0.

Done.

By way of explanation, I chose 0 since (1) BrowserPlugin uses 0 as a null ID:

https://code.google.com/p/chromium/codesearch#chromium/src/content/common/bro...

and secondly I'm always paranoid about someone possible using unsigned types, in
which -1 becomes a valid (non-zero) id.

But I'm ok with changing it :-)

https://codereview.chromium.org/1308313005/diff/120001/Source/core/events/Whe...
File Source/core/events/WheelEvent.cpp (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/core/events/Whe...
Source/core/events/WheelEvent.cpp:54: , m_resendingPluginId(0)
On 2015/09/15 13:13:07, tdresser wrote:
> Let's default m_resendingPluginId to -1, to avoid confusion with a plugin of
id
> 0.

Done.

https://codereview.chromium.org/1308313005/diff/120001/Source/core/events/Whe...
Source/core/events/WheelEvent.cpp:68: , m_resendingPluginId(0)
On 2015/09/15 13:13:07, tdresser wrote:
> ditto

Done.

https://codereview.chromium.org/1308313005/diff/120001/Source/platform/Platfo...
File Source/platform/PlatformGestureEvent.h (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/platform/Platfo...
Source/platform/PlatformGestureEvent.h:126: ASSERT(m_type ==
PlatformEvent::GestureScrollUpdate);
On 2015/09/15 13:13:08, tdresser wrote:
> In WebInputEventConversion, we populate the plugin id for GestureScrollBegin
and
> GestureScrollEnd as well. Why are we inconsistent?

Done.

We actually mark the bracketing begin/end that we send in the other CL as
resends, so you're right to think we should add that here.

https://codereview.chromium.org/1308313005/diff/120001/Source/platform/Platfo...
Source/platform/PlatformGestureEvent.h:130: return 0;
On 2015/09/15 13:13:08, tdresser wrote:
> Let's return -1 here.

Done.

https://codereview.chromium.org/1308313005/diff/120001/Source/platform/Platfo...
File Source/platform/PlatformWheelEvent.h (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/platform/Platfo...
Source/platform/PlatformWheelEvent.h:67: , m_resendingPluginId(0)
On 2015/09/15 13:13:08, tdresser wrote:
> -1

Done.

https://codereview.chromium.org/1308313005/diff/120001/Source/web/WebViewImpl...
File Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/web/WebViewImpl...
Source/web/WebViewImpl.cpp:690: 
On 2015/09/15 13:13:08, tdresser wrote:
> Remove space.

Done.

https://codereview.chromium.org/1308313005/diff/120001/Source/web/WebViewImpl...
Source/web/WebViewImpl.cpp:715:
mainFrameImpl()->frame()->eventHandler().handleGestureScrollEvent(platformEvent);
On 2015/09/15 13:13:08, tdresser wrote:
> Why do we need to explicitly repost the fling? Can it take the same path that
> other gestures are taking?

No, the GestureFlingStart gets dropped on the floor in EventHandler. Even in
this pathway, doesn't the eventSwallowed = true mean it never propagates past
this point?

https://codereview.chromium.org/1308313005/diff/120001/Source/web/WebViewImpl...
Source/web/WebViewImpl.cpp:1874: endScrollEvent.setScrollGestureData(0, 0, 0, 0,
true, false, 0);
On 2015/09/15 13:13:08, tdresser wrote:
> -1
> 
> We might want to define a constant for this, indicating that this means that
the
> event is not reposted.

Done.

https://codereview.chromium.org/1308313005/diff/120001/Source/web/tests/Visua...
File Source/web/tests/VisualViewportTest.cpp (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/web/tests/Visua...
Source/web/tests/VisualViewportTest.cpp:1616: gsu.setScrollGestureData(-50, -60,
1, 1, false, 0, false);
On 2015/09/15 13:13:08, tdresser wrote:
> -1

Done.

https://codereview.chromium.org/1308313005/diff/120001/Source/web/tests/WebIn...
File Source/web/tests/WebInputEventConversionTest.cpp (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/web/tests/WebIn...
Source/web/tests/WebInputEventConversionTest.cpp:437:
platformGestureEvent.setScrollGestureData(30, 32, 40, 42, true, 0, true);
On 2015/09/15 13:13:08, tdresser wrote:
> -1

Done.

https://codereview.chromium.org/1308313005/diff/120001/Source/web/tests/WebIn...
Source/web/tests/WebInputEventConversionTest.cpp:877: true, false, false, false,
0, true, 0, true, Event::RailsModeHorizontal);
On 2015/09/15 13:13:08, tdresser wrote:
> -1

Done.

https://codereview.chromium.org/1308313005/diff/120001/public/web/WebInputEve...
File public/web/WebInputEvent.h (right):

https://codereview.chromium.org/1308313005/diff/120001/public/web/WebInputEve...
public/web/WebInputEvent.h:417: , resendingPluginId(0)
On 2015/09/15 13:13:08, tdresser wrote:
> -1

Done.

https://codereview.chromium.org/1308313005/diff/120001/public/web/WebInputEve...
public/web/WebInputEvent.h:521: , resendingPluginId(0)
On 2015/09/15 13:13:08, tdresser wrote:
> -1

Done.

[wjmaclean, 2015-09-15 15:02:56]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-09-15 15:03:05]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308313005/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308313005/140001

[tdresser, 2015-09-15 15:28:29]

LGTM, modulo nit / question.

https://codereview.chromium.org/1308313005/diff/120001/Source/web/WebViewImpl...
File Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1308313005/diff/120001/Source/web/WebViewImpl...
Source/web/WebViewImpl.cpp:715:
mainFrameImpl()->frame()->eventHandler().handleGestureScrollEvent(platformEvent);
On 2015/09/15 15:02:48, wjmaclean wrote:
> On 2015/09/15 13:13:08, tdresser wrote:
> > Why do we need to explicitly repost the fling? Can it take the same path
that
> > other gestures are taking?
> 
> No, the GestureFlingStart gets dropped on the floor in EventHandler. Even in
> this pathway, doesn't the eventSwallowed = true mean it never propagates past
> this point?

I wonder if by not swallowing the event we could avoid having to explicitly
repost. I'm not certain either way, but it might be worth trying.

https://codereview.chromium.org/1308313005/diff/140001/Source/platform/Platfo...
File Source/platform/PlatformGestureEvent.h (right):

https://codereview.chromium.org/1308313005/diff/140001/Source/platform/Platfo...
Source/platform/PlatformGestureEvent.h:127: if (isScrollEvent())
isScrollEvent includes pinch events. We might as well use the same condition
you're asserting on here.

[commit-bot: I haz the power, 2015-09-15 15:37:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-15 15:37:25]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[wjmaclean, 2015-09-15 18:53:51]

It seems that not swallowing the event does not remove the need to explicit
report, at least not in any simple manner.

Please let me know if my changes to PlatformGestureEvent::resendingPluginId()
look ok.

https://codereview.chromium.org/1308313005/diff/140001/Source/platform/Platfo...
File Source/platform/PlatformGestureEvent.h (right):

https://codereview.chromium.org/1308313005/diff/140001/Source/platform/Platfo...
Source/platform/PlatformGestureEvent.h:127: if (isScrollEvent())
On 2015/09/15 15:28:29, tdresser wrote:
> isScrollEvent includes pinch events. We might as well use the same condition
> you're asserting on here.

Done.

[wjmaclean, 2015-09-15 18:53:59]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-09-15 18:54:26]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308313005/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308313005/160001

[tdresser, 2015-09-15 19:09:33]

LGTM

[commit-bot: I haz the power, 2015-09-15 22:23:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-15 22:23:08]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Rick Byers, 2015-09-16 14:16:02]

LGTM with nits.

nit: please update the CL description for the new field name.

I assume all the real test coverage here is provided by the new tests in
https://codereview.chromium.org/1308273003/, right?

https://codereview.chromium.org/1308313005/diff/160001/public/web/WebInputEve...
File public/web/WebInputEvent.h (right):

https://codereview.chromium.org/1308313005/diff/160001/public/web/WebInputEve...
public/web/WebInputEvent.h:376: int resendingPluginId;
Nit: please add a brief comment here describing this field (since blink doesn't
appear to use it anyway, just plumb it through).

[wjmaclean, 2015-09-16 19:48:32]

The CQ bit was checked by wjmaclean@chromium.org

[wjmaclean, 2015-09-16 19:48:32]

The patchset sent to the CQ was uploaded after l-g-t-m from
tdresser@chromium.org, rbyers@chromium.org
Link to the patchset: https://codereview.chromium.org/1308313005/#ps180001
(title: "Add comment to explain |resendingPluginId|.")

[commit-bot: I haz the power, 2015-09-16 19:48:43]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308313005/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308313005/180001

[commit-bot: I haz the power, 2015-09-16 21:13:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-16 21:13:24]

Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[wjmaclean, 2015-09-16 21:15:28]

The CQ bit was checked by wjmaclean@chromium.org

[commit-bot: I haz the power, 2015-09-16 21:16:08]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308313005/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308313005/180001

[commit-bot: I haz the power, 2015-09-16 23:11:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-16 23:11:10]

Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[wjmaclean, 2015-09-17 12:23:43]

The CQ bit was checked by wjmaclean@chromium.org

[commit-bot: I haz the power, 2015-09-17 12:23:50]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1308313005/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1308313005/180001

[commit-bot: I haz the power, 2015-09-17 13:21:10]

Committed patchset #10 (id:180001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=202448