Move content/renderer input handling for web input events to ui

Move content/renderer input handling for web input events to ui.

The InputHandlerProxy in content/renderer implements the logic for
sending the intercepted web input events to the compositor. Move this
logic to ui to be used by mus/blimp.

BUG=550531
Committed: https://crrev.com/3a8d056562f51c44bbbf8a1b7dd670af4d058350
Cr-Commit-Position: refs/heads/master@{#361207}

[Khushal, 2015-11-04 00:48:16]

Description was changed from

==========
Move content/renderer input handling for web input events to components

The InputHandlerProxy in content/renderer implements the logic for
sending the intercepted web input events to the compositor. Move this
logic to components/input to be used by mus/blimp.

BUG=550531
==========

to

==========
Move content/renderer input handling for web input events to components

The InputHandlerProxy in content/renderer implements the logic for
sending the intercepted web input events to the compositor. Move this
logic to components/input to be used by mus/blimp.

BUG=550531
==========

[Khushal, 2015-11-04 00:48:16]

khushalsagar@chromium.org changed reviewers:
+ dtrainor@chromium.org

[blundell, 2015-11-04 09:41:17]

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

[blundell, 2015-11-04 09:41:18]

drive-by: input is a really generic name for a component. Could we go with
something that makes this component's purpose more clear now that it's no longer
under //content/renderer but in a much more generic location?

[Khushal, 2015-11-04 17:50:54]

khushalsagar@chromium.org changed reviewers:
+ aelias@chromium.org, tdresser@chromium.org

[Khushal, 2015-11-04 17:53:40]

On 2015/11/04 09:41:18, blundell wrote:
> drive-by: input is a really generic name for a component. Could we go with
> something that makes this component's purpose more clear now that it's no
longer
> under //content/renderer but in a much more generic location?

The component is supposed to be a bridge for handling of web input events by the
compositor. I am not completely sure what would be the best name for it.
+aelias, +tdressor, It would be great if you could suggest something. :)

[Khushal, 2015-11-04 18:29:55]

khushalsagar@chromium.org changed reviewers:
+ boliu@chromium.org, piman@chromium.org, torne@chromium.org

[tdresser, 2015-11-04 19:57:12]

On 2015/11/04 17:53:40, Khushal wrote:
> On 2015/11/04 09:41:18, blundell wrote:
> > drive-by: input is a really generic name for a component. Could we go with
> > something that makes this component's purpose more clear now that it's no
> longer
> > under //content/renderer but in a much more generic location?
> 
> The component is supposed to be a bridge for handling of web input events by
the
> compositor. I am not completely sure what would be the best name for it.
> +aelias, +tdressor, It would be great if you could suggest something. :)

I'm not clear on what granularity is appropriate for components. I see other
components like gpu and ui, which aren't particularly fine grained.

Perhaps input_routing?

[Khushal, 2015-11-04 21:06:39]

On 2015/11/04 19:57:12, tdresser wrote:
> On 2015/11/04 17:53:40, Khushal wrote:
> > On 2015/11/04 09:41:18, blundell wrote:
> > > drive-by: input is a really generic name for a component. Could we go with
> > > something that makes this component's purpose more clear now that it's no
> > longer
> > > under //content/renderer but in a much more generic location?
> > 
> > The component is supposed to be a bridge for handling of web input events by
> the
> > compositor. I am not completely sure what would be the best name for it.
> > +aelias, +tdressor, It would be great if you could suggest something. :)
> 
> I'm not clear on what granularity is appropriate for components. I see other
> components like gpu and ui, which aren't particularly fine grained.
> 
> Perhaps input_routing?

That's why I finally went with input as well, since we have components like
gpu/ui.
input_routing would be good too. I just hope it doesn't make it sound like it
has anything to with the input routing from the browser to the renderer.

[Wez, 2015-11-04 21:20:56]

If it's about handling of input by the compositor then why not
compositor_input or cc_input?

On 4 November 2015 at 13:06, <khushalsagar@chromium.org> wrote:

> On 2015/11/04 19:57:12, tdresser wrote:
>
>> On 2015/11/04 17:53:40, Khushal wrote:
>> > On 2015/11/04 09:41:18, blundell wrote:
>> > > drive-by: input is a really generic name for a component. Could we go
>> with
>> > > something that makes this component's purpose more clear now that
>> it's no
>> > longer
>> > > under //content/renderer but in a much more generic location?
>> >
>> > The component is supposed to be a bridge for handling of web input
>> events by
>> the
>> > compositor. I am not completely sure what would be the best name for it.
>> > +aelias, +tdressor, It would be great if you could suggest something. :)
>>
>
> I'm not clear on what granularity is appropriate for components. I see
>> other
>> components like gpu and ui, which aren't particularly fine grained.
>>
>
> Perhaps input_routing?
>>
>
> That's why I finally went with input as well, since we have components like
> gpu/ui.
> input_routing would be good too. I just hope it doesn't make it sound like
> it
> has anything to with the input routing from the browser to the renderer.
>
> https://codereview.chromium.org/1415953004/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Khushal, 2015-11-04 21:33:54]

On 2015/11/04 21:20:56, Wez wrote:
> If it's about handling of input by the compositor then why not
> compositor_input or cc_input?
> 
> On 4 November 2015 at 13:06, <mailto:khushalsagar@chromium.org> wrote:
> 
> > On 2015/11/04 19:57:12, tdresser wrote:
> >
> >> On 2015/11/04 17:53:40, Khushal wrote:
> >> > On 2015/11/04 09:41:18, blundell wrote:
> >> > > drive-by: input is a really generic name for a component. Could we go
> >> with
> >> > > something that makes this component's purpose more clear now that
> >> it's no
> >> > longer
> >> > > under //content/renderer but in a much more generic location?
> >> >
> >> > The component is supposed to be a bridge for handling of web input
> >> events by
> >> the
> >> > compositor. I am not completely sure what would be the best name for it.
> >> > +aelias, +tdressor, It would be great if you could suggest something. :)
> >>
> >
> > I'm not clear on what granularity is appropriate for components. I see
> >> other
> >> components like gpu and ui, which aren't particularly fine grained.
> >>
> >
> > Perhaps input_routing?
> >>
> >
> > That's why I finally went with input as well, since we have components like
> > gpu/ui.
> > input_routing would be good too. I just hope it doesn't make it sound like
> > it
> > has anything to with the input routing from the browser to the renderer.
> >
> > https://codereview.chromium.org/1415953004/
> >
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

cc_input sounds good to me.
blundell@, would that be better?

[tdresser, 2015-11-04 21:36:00]

On 2015/11/04 21:33:54, Khushal wrote:
> On 2015/11/04 21:20:56, Wez wrote:
> > If it's about handling of input by the compositor then why not
> > compositor_input or cc_input?
> > 
> > On 4 November 2015 at 13:06, <mailto:khushalsagar@chromium.org> wrote:
> > 
> > > On 2015/11/04 19:57:12, tdresser wrote:
> > >
> > >> On 2015/11/04 17:53:40, Khushal wrote:
> > >> > On 2015/11/04 09:41:18, blundell wrote:
> > >> > > drive-by: input is a really generic name for a component. Could we go
> > >> with
> > >> > > something that makes this component's purpose more clear now that
> > >> it's no
> > >> > longer
> > >> > > under //content/renderer but in a much more generic location?
> > >> >
> > >> > The component is supposed to be a bridge for handling of web input
> > >> events by
> > >> the
> > >> > compositor. I am not completely sure what would be the best name for
it.
> > >> > +aelias, +tdressor, It would be great if you could suggest something.
:)
> > >>
> > >
> > > I'm not clear on what granularity is appropriate for components. I see
> > >> other
> > >> components like gpu and ui, which aren't particularly fine grained.
> > >>
> > >
> > > Perhaps input_routing?
> > >>
> > >
> > > That's why I finally went with input as well, since we have components
like
> > > gpu/ui.
> > > input_routing would be good too. I just hope it doesn't make it sound like
> > > it
> > > has anything to with the input routing from the browser to the renderer.
> > >
> > > https://codereview.chromium.org/1415953004/
> > >
> > 
> > To unsubscribe from this group and stop receiving emails from it, send an
> email
> > to mailto:chromium-reviews+unsubscribe@chromium.org.
> 
> cc_input sounds good to me.
> blundell@, would that be better?

I'm fine with cc_input.

[piman, 2015-11-04 23:04:47]

On Wed, Nov 4, 2015 at 1:36 PM, <tdresser@chromium.org> wrote:

> On 2015/11/04 21:33:54, Khushal wrote:
>
>> On 2015/11/04 21:20:56, Wez wrote:
>> > If it's about handling of input by the compositor then why not
>> > compositor_input or cc_input?
>> >
>> > On 4 November 2015 at 13:06, <mailto:khushalsagar@chromium.org> wrote:
>> >
>> > > On 2015/11/04 19:57:12, tdresser wrote:
>> > >
>> > >> On 2015/11/04 17:53:40, Khushal wrote:
>> > >> > On 2015/11/04 09:41:18, blundell wrote:
>> > >> > > drive-by: input is a really generic name for a component. Could
>> we go
>> > >> with
>> > >> > > something that makes this component's purpose more clear now that
>> > >> it's no
>> > >> > longer
>> > >> > > under //content/renderer but in a much more generic location?
>> > >> >
>> > >> > The component is supposed to be a bridge for handling of web input
>> > >> events by
>> > >> the
>> > >> > compositor. I am not completely sure what would be the best name
>> for
>>
> it.
>
>> > >> > +aelias, +tdressor, It would be great if you could suggest
>> something.
>>
> :)
>
>> > >>
>> > >
>> > > I'm not clear on what granularity is appropriate for components. I see
>> > >> other
>> > >> components like gpu and ui, which aren't particularly fine grained.
>> > >>
>> > >
>> > > Perhaps input_routing?
>> > >>
>> > >
>> > > That's why I finally went with input as well, since we have components
>>
> like
>
>> > > gpu/ui.
>> > > input_routing would be good too. I just hope it doesn't make it sound
>> like
>> > > it
>> > > has anything to with the input routing from the browser to the
>> renderer.
>> > >
>> > > https://codereview.chromium.org/1415953004/
>> > >
>> >
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> email
>> > to mailto:chromium-reviews+unsubscribe@chromium.org.
>>
>
> cc_input sounds good to me.
>> blundell@, would that be better?
>>
>
> I'm fine with cc_input.
>

Meh, it doesn't have all that much to do with cc (and indeed that's why
it's not in cc/ today), more about the renderer policies about how it
handles input (things like overscroll, flings, etc.).


>
> https://codereview.chromium.org/1415953004/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[piman, 2015-11-04 23:08:20]

On Wed, Nov 4, 2015 at 3:04 PM, Antoine Labour <piman@chromium.org> wrote:

>
>
> On Wed, Nov 4, 2015 at 1:36 PM, <tdresser@chromium.org> wrote:
>
>> On 2015/11/04 21:33:54, Khushal wrote:
>>
>>> On 2015/11/04 21:20:56, Wez wrote:
>>> > If it's about handling of input by the compositor then why not
>>> > compositor_input or cc_input?
>>> >
>>> > On 4 November 2015 at 13:06, <mailto:khushalsagar@chromium.org> wrote:
>>> >
>>> > > On 2015/11/04 19:57:12, tdresser wrote:
>>> > >
>>> > >> On 2015/11/04 17:53:40, Khushal wrote:
>>> > >> > On 2015/11/04 09:41:18, blundell wrote:
>>> > >> > > drive-by: input is a really generic name for a component. Could
>>> we go
>>> > >> with
>>> > >> > > something that makes this component's purpose more clear now
>>> that
>>> > >> it's no
>>> > >> > longer
>>> > >> > > under //content/renderer but in a much more generic location?
>>> > >> >
>>> > >> > The component is supposed to be a bridge for handling of web input
>>> > >> events by
>>> > >> the
>>> > >> > compositor. I am not completely sure what would be the best name
>>> for
>>>
>> it.
>>
>>> > >> > +aelias, +tdressor, It would be great if you could suggest
>>> something.
>>>
>> :)
>>
>>> > >>
>>> > >
>>> > > I'm not clear on what granularity is appropriate for components. I
>>> see
>>> > >> other
>>> > >> components like gpu and ui, which aren't particularly fine grained.
>>> > >>
>>> > >
>>> > > Perhaps input_routing?
>>> > >>
>>> > >
>>> > > That's why I finally went with input as well, since we have
>>> components
>>>
>> like
>>
>>> > > gpu/ui.
>>> > > input_routing would be good too. I just hope it doesn't make it
>>> sound like
>>> > > it
>>> > > has anything to with the input routing from the browser to the
>>> renderer.
>>> > >
>>> > > https://codereview.chromium.org/1415953004/
>>> > >
>>> >
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> email
>>> > to mailto:chromium-reviews+unsubscribe@chromium.org.
>>>
>>
>> cc_input sounds good to me.
>>> blundell@, would that be better?
>>>
>>
>> I'm fine with cc_input.
>>
>
> Meh, it doesn't have all that much to do with cc (and indeed that's why
> it's not in cc/ today), more about the renderer policies about how it
> handles input (things like overscroll, flings, etc.).
>

How about input_animations?


>
>
>>
>> https://codereview.chromium.org/1415953004/
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Wez, 2015-11-04 23:36:07]

Or input_gestures or input_rendering?

On 4 November 2015 at 15:07, Antoine Labour <piman@chromium.org> wrote:

>
>
> On Wed, Nov 4, 2015 at 3:04 PM, Antoine Labour <piman@chromium.org> wrote:
>
>>
>>
>> On Wed, Nov 4, 2015 at 1:36 PM, <tdresser@chromium.org> wrote:
>>
>>> On 2015/11/04 21:33:54, Khushal wrote:
>>>
>>>> On 2015/11/04 21:20:56, Wez wrote:
>>>> > If it's about handling of input by the compositor then why not
>>>> > compositor_input or cc_input?
>>>> >
>>>> > On 4 November 2015 at 13:06, <mailto:khushalsagar@chromium.org>
>>>> wrote:
>>>> >
>>>> > > On 2015/11/04 19:57:12, tdresser wrote:
>>>> > >
>>>> > >> On 2015/11/04 17:53:40, Khushal wrote:
>>>> > >> > On 2015/11/04 09:41:18, blundell wrote:
>>>> > >> > > drive-by: input is a really generic name for a component.
>>>> Could we go
>>>> > >> with
>>>> > >> > > something that makes this component's purpose more clear now
>>>> that
>>>> > >> it's no
>>>> > >> > longer
>>>> > >> > > under //content/renderer but in a much more generic location?
>>>> > >> >
>>>> > >> > The component is supposed to be a bridge for handling of web
>>>> input
>>>> > >> events by
>>>> > >> the
>>>> > >> > compositor. I am not completely sure what would be the best name
>>>> for
>>>>
>>> it.
>>>
>>>> > >> > +aelias, +tdressor, It would be great if you could suggest
>>>> something.
>>>>
>>> :)
>>>
>>>> > >>
>>>> > >
>>>> > > I'm not clear on what granularity is appropriate for components. I
>>>> see
>>>> > >> other
>>>> > >> components like gpu and ui, which aren't particularly fine grained.
>>>> > >>
>>>> > >
>>>> > > Perhaps input_routing?
>>>> > >>
>>>> > >
>>>> > > That's why I finally went with input as well, since we have
>>>> components
>>>>
>>> like
>>>
>>>> > > gpu/ui.
>>>> > > input_routing would be good too. I just hope it doesn't make it
>>>> sound like
>>>> > > it
>>>> > > has anything to with the input routing from the browser to the
>>>> renderer.
>>>> > >
>>>> > > https://codereview.chromium.org/1415953004/
>>>> > >
>>>> >
>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>> send an
>>>> email
>>>> > to mailto:chromium-reviews+unsubscribe@chromium.org.
>>>>
>>>
>>> cc_input sounds good to me.
>>>> blundell@, would that be better?
>>>>
>>>
>>> I'm fine with cc_input.
>>>
>>
>> Meh, it doesn't have all that much to do with cc (and indeed that's why
>> it's not in cc/ today), more about the renderer policies about how it
>> handles input (things like overscroll, flings, etc.).
>>
>
> How about input_animations?
>
>
>>
>>
>>>
>>> https://codereview.chromium.org/1415953004/
>>>
>>
>>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[piman, 2015-11-05 00:07:48]

On Wed, Nov 4, 2015 at 3:36 PM, Wez <wez@chromium.org> wrote:

> Or input_gestures or input_rendering?
>

I like input_gestures.

Antoine


>
> On 4 November 2015 at 15:07, Antoine Labour <piman@chromium.org> wrote:
>
>>
>>
>> On Wed, Nov 4, 2015 at 3:04 PM, Antoine Labour <piman@chromium.org>
>> wrote:
>>
>>>
>>>
>>> On Wed, Nov 4, 2015 at 1:36 PM, <tdresser@chromium.org> wrote:
>>>
>>>> On 2015/11/04 21:33:54, Khushal wrote:
>>>>
>>>>> On 2015/11/04 21:20:56, Wez wrote:
>>>>> > If it's about handling of input by the compositor then why not
>>>>> > compositor_input or cc_input?
>>>>> >
>>>>> > On 4 November 2015 at 13:06, <mailto:khushalsagar@chromium.org>
>>>>> wrote:
>>>>> >
>>>>> > > On 2015/11/04 19:57:12, tdresser wrote:
>>>>> > >
>>>>> > >> On 2015/11/04 17:53:40, Khushal wrote:
>>>>> > >> > On 2015/11/04 09:41:18, blundell wrote:
>>>>> > >> > > drive-by: input is a really generic name for a component.
>>>>> Could we go
>>>>> > >> with
>>>>> > >> > > something that makes this component's purpose more clear now
>>>>> that
>>>>> > >> it's no
>>>>> > >> > longer
>>>>> > >> > > under //content/renderer but in a much more generic location?
>>>>> > >> >
>>>>> > >> > The component is supposed to be a bridge for handling of web
>>>>> input
>>>>> > >> events by
>>>>> > >> the
>>>>> > >> > compositor. I am not completely sure what would be the best
>>>>> name for
>>>>>
>>>> it.
>>>>
>>>>> > >> > +aelias, +tdressor, It would be great if you could suggest
>>>>> something.
>>>>>
>>>> :)
>>>>
>>>>> > >>
>>>>> > >
>>>>> > > I'm not clear on what granularity is appropriate for components. I
>>>>> see
>>>>> > >> other
>>>>> > >> components like gpu and ui, which aren't particularly fine
>>>>> grained.
>>>>> > >>
>>>>> > >
>>>>> > > Perhaps input_routing?
>>>>> > >>
>>>>> > >
>>>>> > > That's why I finally went with input as well, since we have
>>>>> components
>>>>>
>>>> like
>>>>
>>>>> > > gpu/ui.
>>>>> > > input_routing would be good too. I just hope it doesn't make it
>>>>> sound like
>>>>> > > it
>>>>> > > has anything to with the input routing from the browser to the
>>>>> renderer.
>>>>> > >
>>>>> > > https://codereview.chromium.org/1415953004/
>>>>> > >
>>>>> >
>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>> send an
>>>>> email
>>>>> > to mailto:chromium-reviews+unsubscribe@chromium.org.
>>>>>
>>>>
>>>> cc_input sounds good to me.
>>>>> blundell@, would that be better?
>>>>>
>>>>
>>>> I'm fine with cc_input.
>>>>
>>>
>>> Meh, it doesn't have all that much to do with cc (and indeed that's why
>>> it's not in cc/ today), more about the renderer policies about how it
>>> handles input (things like overscroll, flings, etc.).
>>>
>>
>> How about input_animations?
>>
>>
>>>
>>>
>>>>
>>>> https://codereview.chromium.org/1415953004/
>>>>
>>>
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Khushal, 2015-11-05 00:14:53]

On 2015/11/05 00:07:48, piman (slow to review) wrote:
> On Wed, Nov 4, 2015 at 3:36 PM, Wez <mailto:wez@chromium.org> wrote:
> 
> > Or input_gestures or input_rendering?
> >
> 
> I like input_gestures.
> 
> Antoine
> 
> 
> >
> > On 4 November 2015 at 15:07, Antoine Labour <mailto:piman@chromium.org>
wrote:
> >
> >>
> >>
> >> On Wed, Nov 4, 2015 at 3:04 PM, Antoine Labour <mailto:piman@chromium.org>
> >> wrote:
> >>
> >>>
> >>>
> >>> On Wed, Nov 4, 2015 at 1:36 PM, <mailto:tdresser@chromium.org> wrote:
> >>>
> >>>> On 2015/11/04 21:33:54, Khushal wrote:
> >>>>
> >>>>> On 2015/11/04 21:20:56, Wez wrote:
> >>>>> > If it's about handling of input by the compositor then why not
> >>>>> > compositor_input or cc_input?
> >>>>> >
> >>>>> > On 4 November 2015 at 13:06, <mailto:khushalsagar@chromium.org>
> >>>>> wrote:
> >>>>> >
> >>>>> > > On 2015/11/04 19:57:12, tdresser wrote:
> >>>>> > >
> >>>>> > >> On 2015/11/04 17:53:40, Khushal wrote:
> >>>>> > >> > On 2015/11/04 09:41:18, blundell wrote:
> >>>>> > >> > > drive-by: input is a really generic name for a component.
> >>>>> Could we go
> >>>>> > >> with
> >>>>> > >> > > something that makes this component's purpose more clear now
> >>>>> that
> >>>>> > >> it's no
> >>>>> > >> > longer
> >>>>> > >> > > under //content/renderer but in a much more generic location?
> >>>>> > >> >
> >>>>> > >> > The component is supposed to be a bridge for handling of web
> >>>>> input
> >>>>> > >> events by
> >>>>> > >> the
> >>>>> > >> > compositor. I am not completely sure what would be the best
> >>>>> name for
> >>>>>
> >>>> it.
> >>>>
> >>>>> > >> > +aelias, +tdressor, It would be great if you could suggest
> >>>>> something.
> >>>>>
> >>>> :)
> >>>>
> >>>>> > >>
> >>>>> > >
> >>>>> > > I'm not clear on what granularity is appropriate for components. I
> >>>>> see
> >>>>> > >> other
> >>>>> > >> components like gpu and ui, which aren't particularly fine
> >>>>> grained.
> >>>>> > >>
> >>>>> > >
> >>>>> > > Perhaps input_routing?
> >>>>> > >>
> >>>>> > >
> >>>>> > > That's why I finally went with input as well, since we have
> >>>>> components
> >>>>>
> >>>> like
> >>>>
> >>>>> > > gpu/ui.
> >>>>> > > input_routing would be good too. I just hope it doesn't make it
> >>>>> sound like
> >>>>> > > it
> >>>>> > > has anything to with the input routing from the browser to the
> >>>>> renderer.
> >>>>> > >
> >>>>> > > https://codereview.chromium.org/1415953004/
> >>>>> > >
> >>>>> >
> >>>>> > To unsubscribe from this group and stop receiving emails from it,
> >>>>> send an
> >>>>> email
> >>>>> > to mailto:chromium-reviews+unsubscribe@chromium.org.
> >>>>>
> >>>>
> >>>> cc_input sounds good to me.
> >>>>> blundell@, would that be better?
> >>>>>
> >>>>
> >>>> I'm fine with cc_input.
> >>>>
> >>>
> >>> Meh, it doesn't have all that much to do with cc (and indeed that's why
> >>> it's not in cc/ today), more about the renderer policies about how it
> >>> handles input (things like overscroll, flings, etc.).
> >>>
> >>
> >> How about input_animations?
> >>
> >>
> >>>
> >>>
> >>>>
> >>>> https://codereview.chromium.org/1415953004/
> >>>>
> >>>
> >>>
> >>
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

I think we can say we have a winner then. :)

[Khushal, 2015-11-05 09:00:44]

Description was changed from

==========
Move content/renderer input handling for web input events to components

The InputHandlerProxy in content/renderer implements the logic for
sending the intercepted web input events to the compositor. Move this
logic to components/input to be used by mus/blimp.

BUG=550531
==========

to

==========
Move content/renderer input handling for web input events to components

The InputHandlerProxy in content/renderer implements the logic for
sending the intercepted web input events to the compositor. Move this
logic to components/input_gestures to be used by mus/blimp.

BUG=550531
==========

[blundell, 2015-11-05 09:28:30]

input_gestures sgtm

I agree that there are existing bad examples in //components...I try to push
back whenever I see one going into the tree that I think is too generic.

[tdresser, 2015-11-05 13:48:21]

Not LGTM.

input_gestures is misleading, as "gesture" in our code base refers to a specific
subset of event types, and the code that's been placed in input_gestures handles
other types of events, such as mouse events, and touchpad scrolling.

I'd much prefer "input" to "input_gestures".

[blundell, 2015-11-05 13:54:25]

On 2015/11/05 13:48:21, tdresser wrote:
> Not LGTM.
> 
> input_gestures is misleading, as "gesture" in our code base refers to a
specific
> subset of event types, and the code that's been placed in input_gestures
handles
> other types of events, such as mouse events, and touchpad scrolling.
> 
> I'd much prefer "input" to "input_gestures".

OK, so input_gestures is out. How about input_routing?

From looking at the bug it seems like there's still open discussion on whether
this code should move to //components?

[blundell, 2015-11-05 13:55:30]

On 2015/11/05 13:54:25, blundell wrote:
> On 2015/11/05 13:48:21, tdresser wrote:
> > Not LGTM.
> > 
> > input_gestures is misleading, as "gesture" in our code base refers to a
> specific
> > subset of event types, and the code that's been placed in input_gestures
> handles
> > other types of events, such as mouse events, and touchpad scrolling.
> > 
> > I'd much prefer "input" to "input_gestures".
> 
> OK, so input_gestures is out. How about input_routing?
> 
> From looking at the bug it seems like there's still open discussion on whether
> this code should move to //components?

Or would web_input make sense?

[tdresser, 2015-11-05 13:57:29]

On 2015/11/05 13:55:30, blundell wrote:
> On 2015/11/05 13:54:25, blundell wrote:
> > On 2015/11/05 13:48:21, tdresser wrote:
> > > Not LGTM.
> > > 
> > > input_gestures is misleading, as "gesture" in our code base refers to a
> > specific
> > > subset of event types, and the code that's been placed in input_gestures
> > handles
> > > other types of events, such as mouse events, and touchpad scrolling.
> > > 
> > > I'd much prefer "input" to "input_gestures".
> > 
> > OK, so input_gestures is out. How about input_routing?
> > 
> > From looking at the bug it seems like there's still open discussion on
whether
> > this code should move to //components?
> 
> Or would web_input make sense?

I have a slight preference for input_routing to web_input, but both both sound
fine to me.

[Khushal, 2015-11-05 18:20:25]

On 2015/11/05 13:57:29, tdresser wrote:
> On 2015/11/05 13:55:30, blundell wrote:
> > On 2015/11/05 13:54:25, blundell wrote:
> > > On 2015/11/05 13:48:21, tdresser wrote:
> > > > Not LGTM.
> > > > 
> > > > input_gestures is misleading, as "gesture" in our code base refers to a
> > > specific
> > > > subset of event types, and the code that's been placed in input_gestures
> > > handles
> > > > other types of events, such as mouse events, and touchpad scrolling.
> > > > 
> > > > I'd much prefer "input" to "input_gestures".
> > > 
> > > OK, so input_gestures is out. How about input_routing?
> > > 
> > > From looking at the bug it seems like there's still open discussion on
> whether
> > > this code should move to //components?
> > 
> > Or would web_input make sense?
> 
> I have a slight preference for input_routing to web_input, but both both sound
> fine to me.

web_input would be apt too. The user of the component sees the InputHandlerProxy
API for processing WebInput events for flings/animations. I hope that sounds
good to everyone.

[tdresser, 2015-11-05 18:23:34]

On 2015/11/05 18:20:25, Khushal wrote:
> On 2015/11/05 13:57:29, tdresser wrote:
> > On 2015/11/05 13:55:30, blundell wrote:
> > > On 2015/11/05 13:54:25, blundell wrote:
> > > > On 2015/11/05 13:48:21, tdresser wrote:
> > > > > Not LGTM.
> > > > > 
> > > > > input_gestures is misleading, as "gesture" in our code base refers to
a
> > > > specific
> > > > > subset of event types, and the code that's been placed in
input_gestures
> > > > handles
> > > > > other types of events, such as mouse events, and touchpad scrolling.
> > > > > 
> > > > > I'd much prefer "input" to "input_gestures".
> > > > 
> > > > OK, so input_gestures is out. How about input_routing?
> > > > 
> > > > From looking at the bug it seems like there's still open discussion on
> > whether
> > > > this code should move to //components?
> > > 
> > > Or would web_input make sense?
> > 
> > I have a slight preference for input_routing to web_input, but both both
sound
> > fine to me.
> 
> web_input would be apt too. The user of the component sees the
InputHandlerProxy
> API for processing WebInput events for flings/animations. I hope that sounds
> good to everyone.

web_input LGTM.

[piman, 2015-11-05 19:37:43]

On Thu, Nov 5, 2015 at 10:20 AM, <khushalsagar@chromium.org> wrote:

> On 2015/11/05 13:57:29, tdresser wrote:
>
>> On 2015/11/05 13:55:30, blundell wrote:
>> > On 2015/11/05 13:54:25, blundell wrote:
>> > > On 2015/11/05 13:48:21, tdresser wrote:
>> > > > Not LGTM.
>> > > >
>> > > > input_gestures is misleading, as "gesture" in our code base refers
>> to a
>> > > specific
>> > > > subset of event types, and the code that's been placed in
>> input_gestures
>> > > handles
>> > > > other types of events, such as mouse events, and touchpad scrolling.
>> > > >
>> > > > I'd much prefer "input" to "input_gestures".
>> > >
>> > > OK, so input_gestures is out. How about input_routing?
>> > >
>> > > From looking at the bug it seems like there's still open discussion on
>> whether
>> > > this code should move to //components?
>> >
>> > Or would web_input make sense?
>>
>
> I have a slight preference for input_routing to web_input, but both both
>> sound
>> fine to me.
>>
>
> web_input would be apt too. The user of the component sees the
> InputHandlerProxy
> API for processing WebInput events for flings/animations. I hope that
> sounds
> good to everyone.
>

SGTM


>
> https://codereview.chromium.org/1415953004/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Khushal, 2015-11-05 22:16:53]

Description was changed from

==========
Move content/renderer input handling for web input events to components

The InputHandlerProxy in content/renderer implements the logic for
sending the intercepted web input events to the compositor. Move this
logic to components/input_gestures to be used by mus/blimp.

BUG=550531
==========

to

==========
Move content/renderer input handling for web input events to components

The InputHandlerProxy in content/renderer implements the logic for
sending the intercepted web input events to the compositor. Move this
logic to components/web_input to be used by mus/blimp.

BUG=550531
==========

[Khushal, 2015-11-05 22:16:53]

khushalsagar@chromium.org changed reviewers:
+ danakj@chromium.org, dpranke@chromium.org, sadrul@chromium.org

[Khushal, 2015-11-05 22:18:07]

Renamed.
+dpranke, +sadrul, +danakj for DEPS approval.

[danakj, 2015-11-05 22:28:01]

https://codereview.chromium.org/1415953004/diff/60001/components/web_input/DEPS
File components/web_input/DEPS (right):

https://codereview.chromium.org/1415953004/diff/60001/components/web_input/DE...
components/web_input/DEPS:2: "+cc",
also -cc/blink

Or, does this use anything except a couple headers in cc? How about just DEPSing
on those?

cc/input/input_handler.h
cc/input/scroll_elasticity_helper.h ?

[danakj, 2015-11-05 22:29:16]

https://codereview.chromium.org/1415953004/diff/60001/components/web_input/DEPS
File components/web_input/DEPS (right):

https://codereview.chromium.org/1415953004/diff/60001/components/web_input/DE...
components/web_input/DEPS:13: "+ui/gfx",
do you need all gfx? or just geometry?

[Khushal, 2015-11-05 22:49:49]

https://codereview.chromium.org/1415953004/diff/60001/components/web_input/DEPS
File components/web_input/DEPS (right):

https://codereview.chromium.org/1415953004/diff/60001/components/web_input/DE...
components/web_input/DEPS:2: "+cc",
On 2015/11/05 22:28:01, danakj wrote:
> also -cc/blink
> 
> Or, does this use anything except a couple headers in cc? How about just
DEPSing
> on those?
> 
> cc/input/input_handler.h
> cc/input/scroll_elasticity_helper.h ?

It uses the swap promise monitor as well. Would you prefer if it had specific
DEPS for the cc includes?

https://codereview.chromium.org/1415953004/diff/60001/components/web_input/DE...
components/web_input/DEPS:13: "+ui/gfx",
On 2015/11/05 22:29:16, danakj wrote:
> do you need all gfx? or just geometry?

Just geometry. Done.

[Dirk Pranke, 2015-11-05 22:51:12]

On 2015/11/05 22:18:07, Khushal wrote:
> Renamed.
> +dpranke, +sadrul, +danakj for DEPS approval.

I don't think I'm actually an OWNER for any of the things you're changing ...

[Khushal, 2015-11-05 22:55:56]

On 2015/11/05 22:51:12, Dirk Pranke wrote:
> On 2015/11/05 22:18:07, Khushal wrote:
> > Renamed.
> > +dpranke, +sadrul, +danakj for DEPS approval.
> 
> I don't think I'm actually an OWNER for any of the things you're changing ...

Oh. I needed a review for the webkit includes. Do I need to add one of the API
owners for that?

[Dirk Pranke, 2015-11-05 23:06:12]

On 2015/11/05 22:55:56, Khushal wrote:
> Oh. I needed a review for the webkit includes. Do I need to add one of the API
> owners for that?

Yeah, you should get one of the third_party/WebKit/public/OWNERS to review it.

rbyers@ might be a fine choice :).

[danakj, 2015-11-05 23:07:54]

https://codereview.chromium.org/1415953004/diff/60001/components/web_input/DEPS
File components/web_input/DEPS (right):

https://codereview.chromium.org/1415953004/diff/60001/components/web_input/DE...
components/web_input/DEPS:2: "+cc",
On 2015/11/05 22:49:49, Khushal wrote:
> On 2015/11/05 22:28:01, danakj wrote:
> > also -cc/blink
> > 
> > Or, does this use anything except a couple headers in cc? How about just
> DEPSing
> > on those?
> > 
> > cc/input/input_handler.h
> > cc/input/scroll_elasticity_helper.h ?
> 
> It uses the swap promise monitor as well. Would you prefer if it had specific
> DEPS for the cc includes?

I kinda do, just because this area of the code has grown a bunch of external
APIs out of cc, and I have been pushing back against that and trying to remove
them and get us down to just InputHandler (and I guess SwapPromiseMonitor).

If you don't mind I'd prefer it.

[Khushal, 2015-11-05 23:13:38]

On 2015/11/05 23:06:12, Dirk Pranke wrote:
> On 2015/11/05 22:55:56, Khushal wrote:
> > Oh. I needed a review for the webkit includes. Do I need to add one of the
API
> > owners for that?
> 
> Yeah, you should get one of the third_party/WebKit/public/OWNERS to review it.
> 
> rbyers@ might be a fine choice :).

Ah. Okay. He knows a lot about the input stuff too. Thanks!

[Khushal, 2015-11-05 23:14:13]

khushalsagar@chromium.org changed reviewers:
+ rbyers@chromium.org
- dpranke@chromium.org

[Khushal, 2015-11-05 23:14:55]

On 2015/11/05 23:07:54, danakj wrote:
>
https://codereview.chromium.org/1415953004/diff/60001/components/web_input/DEPS
> File components/web_input/DEPS (right):
> 
>
https://codereview.chromium.org/1415953004/diff/60001/components/web_input/DE...
> components/web_input/DEPS:2: "+cc",
> On 2015/11/05 22:49:49, Khushal wrote:
> > On 2015/11/05 22:28:01, danakj wrote:
> > > also -cc/blink
> > > 
> > > Or, does this use anything except a couple headers in cc? How about just
> > DEPSing
> > > on those?
> > > 
> > > cc/input/input_handler.h
> > > cc/input/scroll_elasticity_helper.h ?
> > 
> > It uses the swap promise monitor as well. Would you prefer if it had
specific
> > DEPS for the cc includes?
> 
> I kinda do, just because this area of the code has grown a bunch of external
> APIs out of cc, and I have been pushing back against that and trying to remove
> them and get us down to just InputHandler (and I guess SwapPromiseMonitor).
> 
> If you don't mind I'd prefer it.

Done.

[danakj, 2015-11-05 23:22:47]

DEPS LGTM

[blundell, 2015-11-06 08:20:17]

Thanks for the naming discussion! I greatly prefer web_input/ to input/ as a
name for this component.

Do you have jam's signoff on this move? On the bug, I never saw him actually
give an LGTM on the move conceptually.

[blundell, 2015-11-06 08:20:47]

On 2015/11/06 08:20:17, blundell wrote:
> Thanks for the naming discussion! I greatly prefer web_input/ to input/ as a
> name for this component.
> 
> Do you have jam's signoff on this move? On the bug, I never saw him actually
> give an LGTM on the move conceptually.

(err, and please don't abuse the fact that I just inadvertently gave an LGTM ;)

[Khushal, 2015-11-09 23:26:03]

Description was changed from

==========
Move content/renderer input handling for web input events to components

The InputHandlerProxy in content/renderer implements the logic for
sending the intercepted web input events to the compositor. Move this
logic to components/web_input to be used by mus/blimp.

BUG=550531
==========

to

==========
Move content/renderer input handling for web input events to ui.

The InputHandlerProxy in content/renderer implements the logic for
sending the intercepted web input events to the compositor. Move this
logic to ui to be used by mus/blimp.

BUG=550531
==========

[Khushal, 2015-11-10 02:14:03]

On 2015/11/06 08:20:47, blundell wrote:
> On 2015/11/06 08:20:17, blundell wrote:
> > Thanks for the naming discussion! I greatly prefer web_input/ to input/ as a
> > name for this component.
> > 
> > Do you have jam's signoff on this move? On the bug, I never saw him actually
> > give an LGTM on the move conceptually.
> 
> (err, and please don't abuse the fact that I just inadvertently gave an LGTM
;)

Thanks blundell, jam suggested that it would be okay to move this code to ui as
well. Sorry about the long naming discussion.

+sadrul, aelias, tdresser, could you take a look at the ui move? Thanks!

[aelias_OOO_until_Jul13, 2015-11-10 20:23:51]

lgtm

[tdresser, 2015-11-11 05:58:24]

LGTM, assuming that we didn't lose any tracing coverage.

https://codereview.chromium.org/1415953004/diff/120001/ui/events/blink/input_...
File ui/events/blink/input_handler_proxy.cc (left):

https://codereview.chromium.org/1415953004/diff/120001/ui/events/blink/input_...
ui/events/blink/input_handler_proxy.cc:245: "type",
WebInputEventTraits::GetName(event.type));
Why did this trace disappear?

[Khushal, 2015-11-11 06:18:26]

https://codereview.chromium.org/1415953004/diff/120001/ui/events/blink/input_...
File ui/events/blink/input_handler_proxy.cc (left):

https://codereview.chromium.org/1415953004/diff/120001/ui/events/blink/input_...
ui/events/blink/input_handler_proxy.cc:245: "type",
WebInputEventTraits::GetName(event.type));
On 2015/11/11 05:58:24, tdresser wrote:
> Why did this trace disappear?

WebInputEventTraits lives in content.

May be we move this trace to where the function call is made right now?
https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/i...

[Khushal, 2015-11-11 06:26:51]

Also, would it be a good idea to add an OWNERS file with the owners from
content/renderer/input to ui/events/blink for the input* files?

[tdresser, 2015-11-11 16:14:14]

On 2015/11/11 06:26:51, Khushal wrote:
> Also, would it be a good idea to add an OWNERS file with the owners from
> content/renderer/input to ui/events/blink for the input* files?

Moving the trace statement SGTM.

Adding that OWNERS file is a good call, thanks.

[Khushal, 2015-11-11 19:38:40]

On 2015/11/11 16:14:14, tdresser wrote:
> On 2015/11/11 06:26:51, Khushal wrote:
> > Also, would it be a good idea to add an OWNERS file with the owners from
> > content/renderer/input to ui/events/blink for the input* files?
> 
> Moving the trace statement SGTM.
> 
> Adding that OWNERS file is a good call, thanks.

Done. Thanks!

[Khushal, 2015-11-16 18:29:24]

On 2015/11/11 19:38:40, Khushal wrote:
> On 2015/11/11 16:14:14, tdresser wrote:
> > On 2015/11/11 06:26:51, Khushal wrote:
> > > Also, would it be a good idea to add an OWNERS file with the owners from
> > > content/renderer/input to ui/events/blink for the input* files?
> > 
> > Moving the trace statement SGTM.
> > 
> > Adding that OWNERS file is a good call, thanks.
> 
> Done. Thanks!

friendly ping. :)

[danakj, 2015-11-16 18:39:24]

https://codereview.chromium.org/1415953004/diff/160001/ui/events/blink/OWNERS
File ui/events/blink/OWNERS (right):

https://codereview.chromium.org/1415953004/diff/160001/ui/events/blink/OWNERS...
ui/events/blink/OWNERS:1: per-file input*=aelias@chromium.org
who's the owner for ui/events/blink/synchronous_input_handler_proxy.h then?

[Khushal, 2015-11-16 18:45:47]

https://codereview.chromium.org/1415953004/diff/160001/ui/events/blink/OWNERS
File ui/events/blink/OWNERS (right):

https://codereview.chromium.org/1415953004/diff/160001/ui/events/blink/OWNERS...
ui/events/blink/OWNERS:1: per-file input*=aelias@chromium.org
On 2015/11/16 18:39:24, danakj (behind on reviews) wrote:
> who's the owner for ui/events/blink/synchronous_input_handler_proxy.h then?

It should be the same owners from content/renderer/input I guess.

[sadrul, 2015-11-16 18:48:32]

lgtm

https://codereview.chromium.org/1415953004/diff/160001/ui/events/blink/OWNERS
File ui/events/blink/OWNERS (right):

https://codereview.chromium.org/1415953004/diff/160001/ui/events/blink/OWNERS...
ui/events/blink/OWNERS:2: per-file input*=tdresser@chromium.org
The only other file in events/blink is Web*Event <--> ui::*Event conversion
code. So you don't need per-file here.

[Khushal, 2015-11-16 19:02:52]

On 2015/11/16 18:48:32, sadrul wrote:
> lgtm
> 
> https://codereview.chromium.org/1415953004/diff/160001/ui/events/blink/OWNERS
> File ui/events/blink/OWNERS (right):
> 
>
https://codereview.chromium.org/1415953004/diff/160001/ui/events/blink/OWNERS...
> ui/events/blink/OWNERS:2: per-file mailto:input*=tdresser@chromium.org
> The only other file in events/blink is Web*Event <--> ui::*Event conversion
> code. So you don't need per-file here.

Done. Thanks!

[boliu, 2015-11-16 19:12:12]

https://codereview.chromium.org/1415953004/diff/200001/content/browser/androi...
File content/browser/android/in_process/synchronous_compositor_impl.h (right):

https://codereview.chromium.org/1415953004/diff/200001/content/browser/androi...
content/browser/android/in_process/synchronous_compositor_impl.h:23: namespace
ui {
Not needed

https://codereview.chromium.org/1415953004/diff/200001/content/renderer/andro...
File content/renderer/android/synchronous_compositor_filter.h (right):

https://codereview.chromium.org/1415953004/diff/200001/content/renderer/andro...
content/renderer/android/synchronous_compositor_filter.h:15: #include
"ui/events/blink/synchronous_input_handler_proxy.h"
I think forward declaration is good enough for this class.

If not, forward declare in header and include in .cc file.

https://codereview.chromium.org/1415953004/diff/200001/content/renderer/andro...
File content/renderer/android/synchronous_compositor_proxy.h (right):

https://codereview.chromium.org/1415953004/diff/200001/content/renderer/andro...
content/renderer/android/synchronous_compositor_proxy.h:30: namespace ui {
not needed

[Rick Byers, 2015-11-16 20:09:25]

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

[Rick Byers, 2015-11-16 20:38:29]

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

[Rick Byers, 2015-11-16 20:38:29]

ui/events/blink/DEPS LGTM (usage of blink types)

[boliu, 2015-11-16 20:54:38]

https://codereview.chromium.org/1415953004/diff/220001/content/browser/androi...
File content/browser/android/in_process/DEPS (right):

https://codereview.chromium.org/1415953004/diff/220001/content/browser/androi...
content/browser/android/in_process/DEPS:4: "+ui/events/blink",
One more. Add only synchronous_input_handler_proxy.h

[Khushal, 2015-11-16 21:12:49]

https://codereview.chromium.org/1415953004/diff/200001/content/browser/androi...
File content/browser/android/in_process/synchronous_compositor_impl.h (right):

https://codereview.chromium.org/1415953004/diff/200001/content/browser/androi...
content/browser/android/in_process/synchronous_compositor_impl.h:23: namespace
ui {
On 2015/11/16 19:12:12, boliu wrote:
> Not needed

Done.

https://codereview.chromium.org/1415953004/diff/200001/content/renderer/andro...
File content/renderer/android/synchronous_compositor_filter.h (right):

https://codereview.chromium.org/1415953004/diff/200001/content/renderer/andro...
content/renderer/android/synchronous_compositor_filter.h:15: #include
"ui/events/blink/synchronous_input_handler_proxy.h"
On 2015/11/16 19:12:12, boliu wrote:
> I think forward declaration is good enough for this class.
> 
> If not, forward declare in header and include in .cc file.

Done.

https://codereview.chromium.org/1415953004/diff/200001/content/renderer/andro...
File content/renderer/android/synchronous_compositor_proxy.h (right):

https://codereview.chromium.org/1415953004/diff/200001/content/renderer/andro...
content/renderer/android/synchronous_compositor_proxy.h:30: namespace ui {
On 2015/11/16 19:12:12, boliu wrote:
> not needed

Done.

https://codereview.chromium.org/1415953004/diff/220001/content/browser/androi...
File content/browser/android/in_process/DEPS (right):

https://codereview.chromium.org/1415953004/diff/220001/content/browser/androi...
content/browser/android/in_process/DEPS:4: "+ui/events/blink",
On 2015/11/16 20:54:38, boliu wrote:
> One more. Add only synchronous_input_handler_proxy.h

Done.

[boliu, 2015-11-16 21:18:07]

synchronous_compositor_* lgtm

https://codereview.chromium.org/1415953004/diff/240001/content/browser/androi...
File content/browser/android/in_process/DEPS (right):

https://codereview.chromium.org/1415953004/diff/240001/content/browser/androi...
content/browser/android/in_process/DEPS:4:
"+ui/events/blink/synchronous_input_handler_proxy.h",
alphabetical order

[Khushal, 2015-11-16 21:24:24]

Thanks Bo!

https://codereview.chromium.org/1415953004/diff/240001/content/browser/androi...
File content/browser/android/in_process/DEPS (right):

https://codereview.chromium.org/1415953004/diff/240001/content/browser/androi...
content/browser/android/in_process/DEPS:4:
"+ui/events/blink/synchronous_input_handler_proxy.h",
On 2015/11/16 21:18:07, boliu wrote:
> alphabetical order

Done.

[piman, 2015-11-16 21:39:44]

lgtm

[Torne, 2015-11-17 13:28:49]

tools/copyright_scanner LGTM

[Khushal, 2015-11-17 16:12:27]

The CQ bit was checked by khushalsagar@chromium.org

[Khushal, 2015-11-17 16:12:27]

The patchset sent to the CQ was uploaded after l-g-t-m from danakj@chromium.org,
blundell@chromium.org, aelias@chromium.org, tdresser@chromium.org,
sadrul@chromium.org, rbyers@chromium.org, boliu@chromium.org
Link to the patchset: https://codereview.chromium.org/1415953004/#ps260001
(title: "DEPS order fix.")

[commit-bot: I haz the power, 2015-11-17 16:13:05]

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

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

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

[commit-bot: I haz the power, 2015-11-17 16:24:01]

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

[Khushal, 2015-11-19 01:15:05]

khushalsagar@chromium.org changed reviewers:
+ stuartmorgan@chromium.org

[Khushal, 2015-11-19 01:15:07]

Had to restructure events.gyp into different files since otherwise it causes a
cyclic dependency in gyp files which ios doesn't allow. Also updated
events_unittests to exclude events/blink tests for ios and content_browser.gypi
to exclude events_blink for ios.
sadrul@, could you take another look?

[Khushal, 2015-11-23 17:28:30]

khushalsagar@chromium.org changed reviewers:
+ agrieve@chromium.org, halliwell@chromium.org

[Khushal, 2015-11-23 17:29:15]

+agrieve to take a look at build/
+halliwell for chromecast/

[halliwell, 2015-11-23 17:49:02]

On 2015/11/23 17:29:15, Khushal wrote:
> +agrieve to take a look at build/
> +halliwell for chromecast/

chromecast/ lgtm

[agrieve, 2015-11-23 18:35:24]

On 2015/11/23 17:49:02, halliwell wrote:
> On 2015/11/23 17:29:15, Khushal wrote:
> > +agrieve to take a look at build/
> > +halliwell for chromecast/
> 
> chromecast/ lgtm

build/ lgtm

[Khushal, 2015-11-23 20:57:01]

The CQ bit was checked by khushalsagar@chromium.org

[Khushal, 2015-11-23 20:57:01]

The patchset sent to the CQ was uploaded after l-g-t-m from aelias@chromium.org,
sadrul@chromium.org, torne@chromium.org, rbyers@chromium.org,
boliu@chromium.org, danakj@chromium.org, piman@chromium.org,
tdresser@chromium.org, blundell@chromium.org
Link to the patchset: https://codereview.chromium.org/1415953004/#ps400001
(title: "Update content_browser.gypi")

[commit-bot: I haz the power, 2015-11-23 20:59:05]

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

[commit-bot: I haz the power, 2015-11-23 21:06:51]

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

[commit-bot: I haz the power, 2015-11-23 21:06:53]

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

[Khushal, 2015-11-23 21:15:25]

The CQ bit was checked by khushalsagar@chromium.org

[Khushal, 2015-11-23 21:15:25]

The patchset sent to the CQ was uploaded after l-g-t-m from aelias@chromium.org,
sadrul@chromium.org, torne@chromium.org, rbyers@chromium.org,
boliu@chromium.org, danakj@chromium.org, halliwell@chromium.org,
piman@chromium.org, agrieve@chromium.org, tdresser@chromium.org,
blundell@chromium.org
Link to the patchset: https://codereview.chromium.org/1415953004/#ps420001
(title: "Rebase.")

[commit-bot: I haz the power, 2015-11-23 21:18:41]

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

[commit-bot: I haz the power, 2015-11-23 22:50:44]

Committed patchset #22 (id:420001)

[commit-bot: I haz the power, 2015-11-23 22:51:51]

Patchset 22 (id:??) landed as
https://crrev.com/3a8d056562f51c44bbbf8a1b7dd670af4d058350
Cr-Commit-Position: refs/heads/master@{#361207}