Changes PlatformWindowMus to ack event callback before dispatching

Changes PlatformWindowMus to ack event callback before dispatching

To do otherwise causes problems with nested message loops.

BUG=none
TEST=none
R=sadrul@chromium.org

Committed: https://crrev.com/b3cb0f1a93ae0ce4ec65d561697802d2bf9f171e
Cr-Commit-Position: refs/heads/master@{#368606}

[sadrul, 2016-01-09 00:20:26]

lgtm (maybe we can convert all menus to be async and won't need this anymore)

[sky, 2016-01-11 16:05:58]

On 2016/01/09 00:20:26, sadrul wrote:
> lgtm (maybe we can convert all menus to be async and won't need this anymore)

Drag and drop is sync, right?

It seems like we need a better solution than an explicit ack. Maybe mojo itself
needs a way to better communicate responsiveness rather than relying on the app,
which is error prone.

[sky, 2016-01-11 16:06:03]

The CQ bit was checked by sky@chromium.org

[commit-bot: I haz the power, 2016-01-11 16:06:15]

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

[Fady Samuel, 2016-01-11 16:07:42]

On 2016/01/11 16:05:58, sky wrote:
> On 2016/01/09 00:20:26, sadrul wrote:
> > lgtm (maybe we can convert all menus to be async and won't need this
anymore)
> 
> Drag and drop is sync, right?
> 
> It seems like we need a better solution than an explicit ack. Maybe mojo
itself
> needs a way to better communicate responsiveness rather than relying on the
app,
> which is error prone.

+1000000 it would be AMAZING if mojo IPC had a way of communicating
responsiveness. There are web platform use cases for this as well.

[commit-bot: I haz the power, 2016-01-11 17:07:23]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-01-11 17:08:12]

Description was changed from

==========
Changes PlatformWindowMus to ack event callback before dispatching

To do otherwise causes problems with nested message loops.

BUG=none
TEST=none
R=sadrul@chromium.org
==========

to

==========
Changes PlatformWindowMus to ack event callback before dispatching

To do otherwise causes problems with nested message loops.

BUG=none
TEST=none
R=sadrul@chromium.org

Committed: https://crrev.com/b3cb0f1a93ae0ce4ec65d561697802d2bf9f171e
Cr-Commit-Position: refs/heads/master@{#368606}
==========

[commit-bot: I haz the power, 2016-01-11 17:08:13]

Patchset 1 (id:??) landed as
https://crrev.com/b3cb0f1a93ae0ce4ec65d561697802d2bf9f171e
Cr-Commit-Position: refs/heads/master@{#368606}

[sky, 2016-01-11 17:10:06]

On 2016/01/11 16:07:42, Fady Samuel wrote:
> On 2016/01/11 16:05:58, sky wrote:
> > On 2016/01/09 00:20:26, sadrul wrote:
> > > lgtm (maybe we can convert all menus to be async and won't need this
> anymore)
> > 
> > Drag and drop is sync, right?
> > 
> > It seems like we need a better solution than an explicit ack. Maybe mojo
> itself
> > needs a way to better communicate responsiveness rather than relying on the
> app,
> > which is error prone.
> 
> +1000000 it would be AMAZING if mojo IPC had a way of communicating
> responsiveness. There are web platform use cases for this as well.

I filed 576305.

[sadrul, 2016-01-11 17:13:52]

On 2016/01/11 17:10:06, sky wrote:
> On 2016/01/11 16:07:42, Fady Samuel wrote:
> > On 2016/01/11 16:05:58, sky wrote:
> > > On 2016/01/09 00:20:26, sadrul wrote:
> > > > lgtm (maybe we can convert all menus to be async and won't need this
> > anymore)
> > > 
> > > Drag and drop is sync, right?
> > > 
> > > It seems like we need a better solution than an explicit ack. Maybe mojo
> > itself
> > > needs a way to better communicate responsiveness rather than relying on
the
> > app,
> > > which is error prone.
> > 
> > +1000000 it would be AMAZING if mojo IPC had a way of communicating
> > responsiveness. There are web platform use cases for this as well.
> 
> I filed 576305.

Note that we still need the explicit ack for the event in the renderer process
as long as the compositor thread is the one that receives the event from mus.

[sky, 2016-01-11 17:19:30]

On 2016/01/11 17:13:52, sadrul wrote:
> On 2016/01/11 17:10:06, sky wrote:
> > On 2016/01/11 16:07:42, Fady Samuel wrote:
> > > On 2016/01/11 16:05:58, sky wrote:
> > > > On 2016/01/09 00:20:26, sadrul wrote:
> > > > > lgtm (maybe we can convert all menus to be async and won't need this
> > > anymore)
> > > > 
> > > > Drag and drop is sync, right?
> > > > 
> > > > It seems like we need a better solution than an explicit ack. Maybe mojo
> > > itself
> > > > needs a way to better communicate responsiveness rather than relying on
> the
> > > app,
> > > > which is error prone.
> > > 
> > > +1000000 it would be AMAZING if mojo IPC had a way of communicating
> > > responsiveness. There are web platform use cases for this as well.
> > 
> > I filed 576305.
> 
> Note that we still need the explicit ack for the event in the renderer process
> as long as the compositor thread is the one that receives the event from mus.

Windows gets along fine without an ack like we've added.

[sadrul, 2016-01-11 17:37:51]

On 2016/01/11 17:19:30, sky wrote:
> On 2016/01/11 17:13:52, sadrul wrote:
> > On 2016/01/11 17:10:06, sky wrote:
> > > On 2016/01/11 16:07:42, Fady Samuel wrote:
> > > > On 2016/01/11 16:05:58, sky wrote:
> > > > > On 2016/01/09 00:20:26, sadrul wrote:
> > > > > > lgtm (maybe we can convert all menus to be async and won't need this
> > > > anymore)
> > > > > 
> > > > > Drag and drop is sync, right?
> > > > > 
> > > > > It seems like we need a better solution than an explicit ack. Maybe
mojo
> > > > itself
> > > > > needs a way to better communicate responsiveness rather than relying
on
> > the
> > > > app,
> > > > > which is error prone.
> > > > 
> > > > +1000000 it would be AMAZING if mojo IPC had a way of communicating
> > > > responsiveness. There are web platform use cases for this as well.
> > > 
> > > I filed 576305.
> > 
> > Note that we still need the explicit ack for the event in the renderer
process
> > as long as the compositor thread is the one that receives the event from
mus.
> 
> Windows gets along fine without an ack like we've added.

The difference here is that for scrolling, mus would need to retarget the
scroll-events to the parent if the target is not ack'ing them quickly enough. (I
do not think Windows does this, but maybe it actually has support for this sort
of bubbling?)