Added experimental tilt and tiltDirection to the Touch interface

Added experimental tilt and tiltDirection to the Touch interface

Tilt reports the angle of the stylus in degrees, in range [0, 90).
Currently available behind the enable-experimental-web-platform-features flag.

TiltDirection is an clockwise angle [-180..180) in relation to the 0X axis.
The angle indicates the direction in which the stylus is tilted. 

Draft spec: https://docs.google.com/document/d/1hRjHN9T3RBKJV6LL6WQMEaw35YD_T-G41X-ZciW18xU/edit

A link to the Chrome patch (https://codereview.chromium.org/755403006/)

BUG=393462

[Rick Byers, 2014-11-26 18:57:33]

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

[Rick Byers, 2014-11-26 18:57:34]

I'd love to be able to do this (see http://crbug.com/393462), but in general we
don't add non-standard web-exposed APIs to blink (blink aims to push the whole
web forward, not just chromium).  See
http://www.chromium.org/blink#launch-process

The first step is probably to discuss this with the standards community and try
to drum up interest from other vendors.  I'd suggest starting by e-mailing
public-touchevents@w3.org and see if you can get some positive feedback for the
idea.  If there's enough interest, we can get it added to the touch event
extensions note: dvcs.w3.org/hg/webevents/raw-file/default/touchevents.html. 
Then a blink intent to implement/ship might have a chance of success.

[d.pikalov, 2014-11-28 14:08:32]

On 2014/11/26 18:57:34, Rick Byers wrote:
> I'd love to be able to do this (see http://crbug.com/393462), but in general
we
> don't add non-standard web-exposed APIs to blink (blink aims to push the whole
> web forward, not just chromium).  See
> http://www.chromium.org/blink#launch-process
> 
> The first step is probably to discuss this with the standards community and
try
> to drum up interest from other vendors.  I'd suggest starting by e-mailing
> mailto:public-touchevents@w3.org and see if you can get some positive feedback
for the
> idea.  If there's enough interest, we can get it added to the touch event
> extensions note: dvcs.w3.org/hg/webevents/raw-file/default/touchevents.html. 
> Then a blink intent to implement/ship might have a chance of success.

Thanks for your comments, I'll check #launch-process

[Rick Byers, 2015-01-28 21:43:57]

On 2014/11/28 14:08:32, d.pikalov wrote:
> On 2014/11/26 18:57:34, Rick Byers wrote:
> > I'd love to be able to do this (see http://crbug.com/393462), but in general
> we
> > don't add non-standard web-exposed APIs to blink (blink aims to push the
whole
> > web forward, not just chromium).  See
> > http://www.chromium.org/blink#launch-process
> > 
> > The first step is probably to discuss this with the standards community and
> try
> > to drum up interest from other vendors.  I'd suggest starting by e-mailing
> > mailto:public-touchevents@w3.org and see if you can get some positive
feedback
> for the
> > idea.  If there's enough interest, we can get it added to the touch event
> > extensions note: dvcs.w3.org/hg/webevents/raw-file/default/touchevents.html.

> > Then a blink intent to implement/ship might have a chance of success.
> 
> Thanks for your comments, I'll check #launch-process

Based on some interest from the touch events CG
(https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0114.html), I'd
support landing something like this as an experiment (behind the
--enable-experimental-web-platform-features flag).  Next step, if you're
interested, is to probably whip up a rough doc defining the new APIs precisely,
and fire off an "intent to implement" thread on blink-dev (with a link to the
public-touchevents discussion).  Hopefully having this land as experimental in
chrome will help move the standards discussion forward more quickly.

[d.pikalov, 2015-01-30 11:50:09]

On 2015/01/28 21:43:57, Rick Byers wrote:
> On 2014/11/28 14:08:32, d.pikalov wrote:
> > On 2014/11/26 18:57:34, Rick Byers wrote:
> > > I'd love to be able to do this (see http://crbug.com/393462), but in
general
> > we
> > > don't add non-standard web-exposed APIs to blink (blink aims to push the
> whole
> > > web forward, not just chromium).  See
> > > http://www.chromium.org/blink#launch-process
> > > 
> > > The first step is probably to discuss this with the standards community
and
> > try
> > > to drum up interest from other vendors.  I'd suggest starting by e-mailing
> > > mailto:public-touchevents@w3.org and see if you can get some positive
> feedback
> > for the
> > > idea.  If there's enough interest, we can get it added to the touch event
> > > extensions note:
dvcs.w3.org/hg/webevents/raw-file/default/touchevents.html.
> 
> > > Then a blink intent to implement/ship might have a chance of success.
> > 
> > Thanks for your comments, I'll check #launch-process
> 
> Based on some interest from the touch events CG
> (https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0114.html),
I'd
> support landing something like this as an experiment (behind the
> --enable-experimental-web-platform-features flag).  Next step, if you're
> interested, is to probably whip up a rough doc defining the new APIs
precisely,
> and fire off an "intent to implement" thread on blink-dev (with a link to the
> public-touchevents discussion).  Hopefully having this land as experimental in
> chrome will help move the standards discussion forward more quickly.

Done,
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ewIxA2P3bks

[d.pikalov, 2015-02-04 10:48:53]

Patchset #2 (id:20001) has been deleted

[d.pikalov, 2015-02-04 11:08:23]

Touch.tilt available behind the enable-experimental-web-platform-features flag

[Rick Byers, 2015-02-04 11:48:56]

This looks reasonable overall.  But you're going to change it to use the new API
(with tiltDirection), right?

It's probably worth having a simple doc somewhere with the definition we want to
see added to the spec (nothing complicated - can have links to the e-mail
threads for motivation).  Just so this CL can point at more than some e-mail
threads.

Also please add/extend some tests for both the CreateTouch API addition and
receiving events (which will include updating event_sender.cc in chromium to be
able to set the tilt properties).

https://codereview.chromium.org/750013004/diff/60001/Source/core/dom/Document...
File Source/core/dom/Document.idl (right):

https://codereview.chromium.org/750013004/diff/60001/Source/core/dom/Document...
Source/core/dom/Document.idl:194: [Default=Undefined] optional float webkitTilt,
New arguments must be last to avoid changing the semantics of any existing code
out there on the web.

https://codereview.chromium.org/750013004/diff/60001/Source/core/page/EventHa...
File Source/core/page/EventHandler.cpp (left):

https://codereview.chromium.org/750013004/diff/60001/Source/core/page/EventHa...
Source/core/page/EventHandler.cpp:100: 
was this on purpose?

[d.pikalov, 2015-02-04 13:39:41]

> This looks reasonable overall.  But you're going to change it to use the new
API
> (with tiltDirection), right?
Right, I'll add tiltDirection soon

> It's probably worth having a simple doc somewhere with the definition we want
to
> see added to the spec (nothing complicated - can have links to the e-mail
> threads for motivation).  Just so this CL can point at more than some e-mail
> threads.
Ok

> Also please add/extend some tests for both the CreateTouch API addition and
> receiving events (which will include updating event_sender.cc in chromium to
be
> able to set the tilt properties).
Ok

[d.pikalov, 2015-02-11 11:17:13]

https://codereview.chromium.org/750013004/diff/60001/Source/core/dom/Document...
File Source/core/dom/Document.idl (right):

https://codereview.chromium.org/750013004/diff/60001/Source/core/dom/Document...
Source/core/dom/Document.idl:194: [Default=Undefined] optional float webkitTilt,
On 2015/02/04 11:48:55, Rick Byers wrote:
> New arguments must be last to avoid changing the semantics of any existing
code
> out there on the web.

Done.

https://codereview.chromium.org/750013004/diff/60001/Source/core/page/EventHa...
File Source/core/page/EventHandler.cpp (left):

https://codereview.chromium.org/750013004/diff/60001/Source/core/page/EventHa...
Source/core/page/EventHandler.cpp:100: 
On 2015/02/04 11:48:56, Rick Byers wrote:
> was this on purpose?

Done.

[d.pikalov, 2015-02-11 11:22:49]

On 2015/02/04 13:39:41, d.pikalov wrote:

> > It's probably worth having a simple doc somewhere with the definition we
want
> to
> > see added to the spec (nothing complicated - can have links to the e-mail
> > threads for motivation).  Just so this CL can point at more than some e-mail
> > threads.

Here is draft
https://docs.google.com/document/d/1hRjHN9T3RBKJV6LL6WQMEaw35YD_T-G41X-ZciW18...

[Rick Byers, 2015-02-13 08:34:36]

On 2015/02/11 11:22:49, d.pikalov wrote:
> On 2015/02/04 13:39:41, d.pikalov wrote:
> 
> > > It's probably worth having a simple doc somewhere with the definition we
> want
> > to
> > > see added to the spec (nothing complicated - can have links to the e-mail
> > > threads for motivation).  Just so this CL can point at more than some
e-mail
> > > threads.
> 
> Here is draft
>
https://docs.google.com/document/d/1hRjHN9T3RBKJV6LL6WQMEaw35YD_T-G41X-ZciW18...

Thanks!  Can you please enable comments?  publicly-commentable doesn't typically
result in spam.  It looks reasonable to me.  My only suggestion is that perhaps
we can avoid adding a new 'touchchanged' event type and follow the pattern in
pointer events: require a touchmove to be sent whenever any property (not just
position) is changed for the touch.  Other than the obvious name confusion, I
don't think there's much value in treating the different types of property
changes as different events.  WDYT?

[Rick Byers, 2015-02-13 08:48:05]

This looks almost ready to land to me.  I updated your description to add the
right bug number etc.  Please also update it to mention tiltDirection.

https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
File Source/core/dom/Document.cpp (right):

https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
Source/core/dom/Document.cpp:5151: tilt = 0;
you wanted to preserve NaN, right?  This adjusting to 0 was just for
compatibility with when we use to take integer values.  You don't have that
problem.  But it could also be reasonable to prohibit Infinite and NaN values
(whatever your draft spec says on this is OK with me for now - these are details
we can leave to proper standardization).

https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
File Source/core/dom/Document.idl (right):

https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
Source/core/dom/Document.idl:195: [Default=Undefined] optional float webkitTilt,
remove webkit prefix - that's legacy.  In fact only 'webkitRotationAngle' is
still only available by a prefix (so webkitForce/radius* could also have the
prefix removed if you like).

https://codereview.chromium.org/750013004/diff/120001/Source/web/WebInputEven...
File Source/web/WebInputEventConversion.cpp (right):

https://codereview.chromium.org/750013004/diff/120001/Source/web/WebInputEven...
Source/web/WebInputEventConversion.cpp:441: m_tiltDirection =
point.tiltDirection;
Your spec should clarify whether this is intended to take transforms into
account.  Eg. I assume the '0X' axis is relative to current screen rotation. 
But it's physical screen orientation it's relative to, not the co-ordinate
system of the input co-ordinates, right?  Eg. what if I'm receiving the events
inside of an iframe whcih is being spun with a rotation transform.

[d.pikalov, 2015-02-13 13:31:17]

https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
File Source/core/dom/Document.cpp (right):

https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
Source/core/dom/Document.cpp:5151: tilt = 0;
On 2015/02/13 08:48:05, Rick Byers wrote:
> you wanted to preserve NaN, right?  This adjusting to 0 was just for
> compatibility with when we use to take integer values.  You don't have that
> problem.  But it could also be reasonable to prohibit Infinite and NaN values
> (whatever your draft spec says on this is OK with me for now - these are
details
> we can leave to proper standardization).

Right. I have new patchset, with NaN support (I'll upload this bit later today).

https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
File Source/core/dom/Document.idl (right):

https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
Source/core/dom/Document.idl:195: [Default=Undefined] optional float webkitTilt,
On 2015/02/13 08:48:05, Rick Byers wrote:
> remove webkit prefix - that's legacy.  In fact only 'webkitRotationAngle' is
> still only available by a prefix (so webkitForce/radius* could also have the
> prefix removed if you like).

Also, we have to remove those webkit-prefixed properties in Touch.idl, right ?

https://codereview.chromium.org/750013004/diff/120001/Source/web/WebInputEven...
File Source/web/WebInputEventConversion.cpp (right):

https://codereview.chromium.org/750013004/diff/120001/Source/web/WebInputEven...
Source/web/WebInputEventConversion.cpp:441: m_tiltDirection =
point.tiltDirection;
On 2015/02/13 08:48:05, Rick Byers wrote:
> Your spec should clarify whether this is intended to take transforms into
> account.  Eg. I assume the '0X' axis is relative to current screen rotation. 
> But it's physical screen orientation it's relative to, not the co-ordinate
> system of the input co-ordinates, right?  Eg. what if I'm receiving the events
> inside of an iframe whcih is being spun with a rotation transform.

Right, I updated spec with "...angle in relation to the 0X axis of the current
screen orientation..."

[d.pikalov, 2015-02-13 14:50:29]

> Can you please enable comments?
Sure, done

> My only suggestion is that perhaps
> we can avoid adding a new 'touchchanged' event type and follow the pattern in
> pointer events: require a touchmove to be sent whenever any property (not just
> position) is changed for the touch.  Other than the obvious name confusion,
Yes, name is confusing, but I think there should be some way to solve this issue
in long term, right?
Btw, what are drawbacks of adding touchchanged ?

> I don't think there's much value in treating the different types of property
> changes as different events.  WDYT?
True

[d.pikalov, 2015-02-17 09:58:00]

d.pikalov@partner.samsung.com changed reviewers:
+ jochen@chromium.org
- d.pikalov@partner.samsung.com

[d.pikalov, 2015-02-19 09:19:28]

The CQ bit was checked by d.pikalov@partner.samsung.com

[d.pikalov, 2015-02-19 09:19:35]

The CQ bit was unchecked by d.pikalov@partner.samsung.com

[d.pikalov, 2015-02-19 09:19:36]

The CQ bit was checked by d.pikalov@partner.samsung.com

[d.pikalov, 2015-02-19 09:19:43]

The CQ bit was unchecked by d.pikalov@partner.samsung.com

[d.pikalov, 2015-02-19 09:19:50]

The CQ bit was checked by d.pikalov@partner.samsung.com

[d.pikalov, 2015-02-19 09:20:08]

The CQ bit was unchecked by d.pikalov@partner.samsung.com

[Rick Byers, 2015-02-19 17:24:57]

Sorry for the delay, I didn't realize you had uploaded your new patchset.

There's one more thing I forgot (sorry) - you really should have a simple test
that these properties actually get plumbed through correctly (in particular,
what value do you get in the common case of having no tilt info).  You could
update fast/events/touch/script-tests/basic-single-touch-events.js to also check
the default value of tilt and tiltDirection (looks like we're checking radius
there but not force, oops), and then maybe add one simple new test that just
verifies tilt and tiltDirection can be plumbed through correctly via eventSender
(fast/events/touch/touch-event-cancelable.html is a recent simple test that does
something like that).  This will unfortunately require updating event_sender.cc
in chromium to add new methods for setting the tilt and tiltDirection.

On 2015/02/13 13:31:17, d.pikalov wrote:
>
https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
> File Source/core/dom/Document.cpp (right):
> 
>
https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
> Source/core/dom/Document.cpp:5151: tilt = 0;
> On 2015/02/13 08:48:05, Rick Byers wrote:
> > you wanted to preserve NaN, right?  This adjusting to 0 was just for
> > compatibility with when we use to take integer values.  You don't have that
> > problem.  But it could also be reasonable to prohibit Infinite and NaN
values
> > (whatever your draft spec says on this is OK with me for now - these are
> details
> > we can leave to proper standardization).
> 
> Right. I have new patchset, with NaN support (I'll upload this bit later
today).
> 
>
https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
> File Source/core/dom/Document.idl (right):
> 
>
https://codereview.chromium.org/750013004/diff/120001/Source/core/dom/Documen...
> Source/core/dom/Document.idl:195: [Default=Undefined] optional float
webkitTilt,
> On 2015/02/13 08:48:05, Rick Byers wrote:
> > remove webkit prefix - that's legacy.  In fact only 'webkitRotationAngle' is
> > still only available by a prefix (so webkitForce/radius* could also have the
> > prefix removed if you like).
> 
> Also, we have to remove those webkit-prefixed properties in Touch.idl, right ?

I'd like to, yes - but that's technically a breaking web-exposed change so we
need to follow the intent to depricate and remove process.  I filed
http://crbug.com/460099 to track.

>
https://codereview.chromium.org/750013004/diff/120001/Source/web/WebInputEven...
> File Source/web/WebInputEventConversion.cpp (right):
> 
>
https://codereview.chromium.org/750013004/diff/120001/Source/web/WebInputEven...
> Source/web/WebInputEventConversion.cpp:441: m_tiltDirection =
> point.tiltDirection;
> On 2015/02/13 08:48:05, Rick Byers wrote:
> > Your spec should clarify whether this is intended to take transforms into
> > account.  Eg. I assume the '0X' axis is relative to current screen rotation.

> > But it's physical screen orientation it's relative to, not the co-ordinate
> > system of the input co-ordinates, right?  Eg. what if I'm receiving the
events
> > inside of an iframe whcih is being spun with a rotation transform.
> 
> Right, I updated spec with "...angle in relation to the 0X axis of the current
> screen orientation..."

Great, thanks.

On 2015/02/13 14:50:29, d.pikalov wrote:
> > Can you please enable comments?
> Sure, done
> 
> > My only suggestion is that perhaps
> > we can avoid adding a new 'touchchanged' event type and follow the pattern
in
> > pointer events: require a touchmove to be sent whenever any property (not
just
> > position) is changed for the touch.  Other than the obvious name confusion,
> Yes, name is confusing, but I think there should be some way to solve this
issue
> in long term, right?
> Btw, what are drawbacks of adding touchchanged ?

I expect the tilt to change slightly on every movement.  It may also be
difficult to change tilt without changing position slightly.  So in the common
cases it seems unfortunate to pay the cost of dispatching two different events
each frame (touchmove and touchchanged).  Also a painting app will likely want
to draw something exactly once for each frame, so they'd have to decide whether
to draw on the 'toucchanged' or 'touchmove' event and then we'd probably want to
specify which order the two events are expected to arrive in, and whether the
Touch objects seen in the first event have the changes described by the second
one (even though that event hasn't been dispatched yet).

All in all I think it ends up being a lot simpler to have a single event.  Even
pointer events (which was designed from scratch to support stylus) has only a
single 'pointermoved' event which is defined to fire even when only tilt has
changed:
https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-poin...

> > I don't think there's much value in treating the different types of property
> > changes as different events.  WDYT?
> True

[Rick Byers, 2015-02-19 17:25:41]

BTW, I added a link to your draft spec to the CL description.

[d.pikalov, 2015-03-17 11:08:19]

Keep eventSender.setTouchPointTilt under "if", until chrome patch landed.

Added 4th argument (set_state_moved)

[Rick Byers, 2015-03-17 14:38:48]

LGTM with nits

https://codereview.chromium.org/750013004/diff/220001/LayoutTests/fast/events...
File LayoutTests/fast/events/touch/touch-tilt.html (right):

https://codereview.chromium.org/750013004/diff/220001/LayoutTests/fast/events...
LayoutTests/fast/events/touch/touch-tilt.html:12: touch = event.touches.item(0);
nit: touches is an array, so access to item 0 is almost always written as
"touches[0]" rather than using the 'item' function.

https://codereview.chromium.org/750013004/diff/220001/LayoutTests/fast/events...
LayoutTests/fast/events/touch/touch-tilt.html:29:
eventSender.clearTouchPoints();
you should probably call evendSender.touchEnd() here, otherwise I think the
event stream is invalid (the touch went away without ever sending an event
saying it did).  You can probably get away with this today, but we're hoping to
add more validation logic to catch such invalid states.

https://codereview.chromium.org/750013004/diff/220001/LayoutTests/fast/events...
LayoutTests/fast/events/touch/touch-tilt.html:33: eventSender.touchStart();
you should verify the tilt after touchstart too - just add your handler to both
touchmove and touchstart events.

[d.pikalov, 2015-03-17 15:59:10]

Patchset #12 (id:240001) has been deleted

[d.pikalov, 2015-03-17 16:15:51]

Test touch-tilt fixed

https://codereview.chromium.org/750013004/diff/220001/LayoutTests/fast/events...
File LayoutTests/fast/events/touch/touch-tilt.html (right):

https://codereview.chromium.org/750013004/diff/220001/LayoutTests/fast/events...
LayoutTests/fast/events/touch/touch-tilt.html:12: touch = event.touches.item(0);
On 2015/03/17 14:38:48, Rick Byers wrote:
> nit: touches is an array, so access to item 0 is almost always written as
> "touches[0]" rather than using the 'item' function.

Done.

https://codereview.chromium.org/750013004/diff/220001/LayoutTests/fast/events...
LayoutTests/fast/events/touch/touch-tilt.html:29:
eventSender.clearTouchPoints();
On 2015/03/17 14:38:48, Rick Byers wrote:
> you should probably call evendSender.touchEnd() here, otherwise I think the
> event stream is invalid (the touch went away without ever sending an event
> saying it did).  You can probably get away with this today, but we're hoping
to
> add more validation logic to catch such invalid states.

Done.

https://codereview.chromium.org/750013004/diff/220001/LayoutTests/fast/events...
LayoutTests/fast/events/touch/touch-tilt.html:33: eventSender.touchStart();
On 2015/03/17 14:38:47, Rick Byers wrote:
> you should verify the tilt after touchstart too - just add your handler to
both
> touchmove and touchstart events.

Done.

[d.pikalov, 2015-03-18 13:47:48]

The CQ bit was checked by d.pikalov@partner.samsung.com

[d.pikalov, 2015-03-18 13:47:49]

The patchset sent to the CQ was uploaded after l-g-t-m from rbyers@chromium.org
Link to the patchset: https://codereview.chromium.org/750013004/#ps280001
(title: "fixed touch-tilt.html")

[commit-bot: I haz the power, 2015-03-18 13:48:00]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/750013004/280001

[commit-bot: I haz the power, 2015-03-18 13:51:18]

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

[commit-bot: I haz the power, 2015-03-18 13:51:19]

Try jobs failed on following builders:
  mac_blink_rel on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/48034)

[d.pikalov, 2015-03-18 14:02:06]

d.pikalov@partner.samsung.com changed reviewers:
+ adamk@chromium.org

[d.pikalov, 2015-03-18 14:37:54]

The CQ bit was checked by d.pikalov@partner.samsung.com

[d.pikalov, 2015-03-18 14:37:54]

The patchset sent to the CQ was uploaded after l-g-t-m from rbyers@chromium.org
Link to the patchset: https://codereview.chromium.org/750013004/#ps300001
(title: "Merged with master")

[commit-bot: I haz the power, 2015-03-18 14:38:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/750013004/300001

[commit-bot: I haz the power, 2015-03-18 14:44:03]

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

[commit-bot: I haz the power, 2015-03-18 14:44:04]

Try jobs failed on following builders:
  blink_presubmit on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/2...)

[d.pikalov, 2015-03-18 14:48:37]

d.pikalov@partner.samsung.com changed reviewers:
- jochen@chromium.org

[d.pikalov, 2015-03-18 14:50:39]

On 2015/03/18 14:48:38, d.pikalov wrote:

+adamk, please review

[adamk, 2015-03-18 15:56:38]

lgtm for Source/web and Source/platform (rbyers, strangely enough, is in
public/OWNERS but not Source/web/OWNERS).

[d.pikalov, 2015-03-18 15:59:23]

The CQ bit was checked by d.pikalov@partner.samsung.com

[commit-bot: I haz the power, 2015-03-18 16:05:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/750013004/300001

[commit-bot: I haz the power, 2015-03-18 16:25:08]

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

[commit-bot: I haz the power, 2015-03-18 16:25:10]

Try jobs failed on following builders:
  linux_chromium_gn_rel on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/linux_chromium_gn_rel/bu...)

[d.pikalov, 2015-03-19 11:32:43]

The CQ bit was checked by d.pikalov@partner.samsung.com

[d.pikalov, 2015-03-19 11:32:43]

The patchset sent to the CQ was uploaded after l-g-t-m from rbyers@chromium.org,
adamk@chromium.org
Link to the patchset: https://codereview.chromium.org/750013004/#ps320001
(title: "Fixed WebInputEventConversionTest")

[commit-bot: I haz the power, 2015-03-19 11:32:59]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/750013004/320001

[commit-bot: I haz the power, 2015-03-19 12:47:24]

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

[commit-bot: I haz the power, 2015-03-19 12:47:25]

Try jobs failed on following builders:
  linux_blink_rel on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/5...)