Bubble scroll events from WebView guest to embedder.

Bubble scroll events from WebView guest to embedder.

This CL implements a synchronous scroll-bubbling pathway
between an embedder and its guest. For scroll events
(currently MouseWheel and GestureScrollBegin/Update/End),
it passes relevant events to the guest, and waits to
receive the event status (consumed, not consumed) back
from the guest before BrowserPlugin indicates whether the
event was handled or not.

Although this blocks the embedder's main thread for scrolls,
it is simpler to do this, and when OOPIF scrolling is
implemented and WebView switches to use it, this pathway
will disappear.

For more details on scrolling event flow between embedder
and guest, and for the rationale for implementing a
synchronous solution, please refer to the "WebView" section
at the end of:

https://docs.google.com/document/d/1s6zuJaxet0fYs9isRnfS9Karad12GjxcgpT3ppbTjUQ/edit

BUG=491940

[wjmaclean, 2015-08-10 14:29:54]

wjmaclean@chromium.org changed reviewers:
+ creis@chromium.org

[wjmaclean, 2015-08-10 14:31:20]

creis@ I still need to refine the issue description to make it clearer, but
could you please take a first look at this? I'm happy to chat about this CL if
you like, though I'm currently +9 hrs ahead of you (I think)

[Fady Samuel, 2015-08-10 14:58:19]

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

[Fady Samuel, 2015-08-10 14:58:19]

This approach will not work. It will result in potential deadlocks. The guest
can block on the embedder (dialog API). If the embedder can also block on the
guest, then we introduce the risk of deadlocks. Scroll bubbling must be async.

[wjmaclean, 2015-08-11 07:56:40]

On 2015/08/10 14:58:19, Fady Samuel wrote:
> This approach will not work. It will result in potential deadlocks. The guest
> can block on the embedder (dialog API). If the embedder can also block on the
> guest, then we introduce the risk of deadlocks. Scroll bubbling must be async.

Can you elaborate a bit on how the deadlocks would happen? You mention dialog
API ... would the deadlock occur when a dialog in the embedder is triggered on
some event that the guest is also expected to handle?

It would help me to rethink this if you could suggest some specific examples
(that I could eventually use as test cases).

[Fady Samuel, 2015-08-11 12:31:39]

On 2015/08/11 07:56:40, wjmaclean (OOO Aug 4-7) wrote:
> On 2015/08/10 14:58:19, Fady Samuel wrote:
> > This approach will not work. It will result in potential deadlocks. The
guest
> > can block on the embedder (dialog API). If the embedder can also block on
the
> > guest, then we introduce the risk of deadlocks. Scroll bubbling must be
async.
> 
> Can you elaborate a bit on how the deadlocks would happen? You mention dialog
> API ... would the deadlock occur when a dialog in the embedder is triggered on
> some event that the guest is also expected to handle?
> 
> It would help me to rethink this if you could suggest some specific examples
> (that I could eventually use as test cases).

It would deadlock when a dialog (alert/confirm/prompt) is initiated from the
guest. It would also lock up the embedder if the guest crashes. I had a similar
approach to this 4 years ago, and Darin and Rob asked me to drop it.

[Fady Samuel, 2015-08-11 12:41:59]

On 2015/08/11 12:31:39, Fady Samuel wrote:
> On 2015/08/11 07:56:40, wjmaclean (OOO Aug 4-7) wrote:
> > On 2015/08/10 14:58:19, Fady Samuel wrote:
> > > This approach will not work. It will result in potential deadlocks. The
> guest
> > > can block on the embedder (dialog API). If the embedder can also block on
> the
> > > guest, then we introduce the risk of deadlocks. Scroll bubbling must be
> async.
> > 
> > Can you elaborate a bit on how the deadlocks would happen? You mention
dialog
> > API ... would the deadlock occur when a dialog in the embedder is triggered
on
> > some event that the guest is also expected to handle?
> > 
> > It would help me to rethink this if you could suggest some specific examples
> > (that I could eventually use as test cases).
> 
> It would deadlock when a dialog (alert/confirm/prompt) is initiated from the
> guest. It would also lock up the embedder if the guest crashes. I had a
similar
> approach to this 4 years ago, and Darin and Rob asked me to drop it.

The exact deadlock situation with the dialog API is this.

1. The guest sends out a FrameHostMsg_RunJavaScriptMessage.
2. A scroll begins on the guest in the embedder before the embedder handles the
message above, and starts waiting on scroll response from the guest.
3. DEADLOCK.

There are likely other deadlocks around plugin support. This is a fundamental
issue of the web platform, modal dialogs are bad...

[wjmaclean, 2015-08-11 13:05:23]

On 2015/08/11 12:41:59, Fady Samuel wrote:
> On 2015/08/11 12:31:39, Fady Samuel wrote:
> > On 2015/08/11 07:56:40, wjmaclean (OOO Aug 4-7) wrote:
> > > On 2015/08/10 14:58:19, Fady Samuel wrote:
> > > > This approach will not work. It will result in potential deadlocks. The
> > guest
> > > > can block on the embedder (dialog API). If the embedder can also block
on
> > the
> > > > guest, then we introduce the risk of deadlocks. Scroll bubbling must be
> > async.
> > > 
> > > Can you elaborate a bit on how the deadlocks would happen? You mention
> dialog
> > > API ... would the deadlock occur when a dialog in the embedder is
triggered
> on
> > > some event that the guest is also expected to handle?
> > > 
> > > It would help me to rethink this if you could suggest some specific
examples
> > > (that I could eventually use as test cases).
> > 
> > It would deadlock when a dialog (alert/confirm/prompt) is initiated from the
> > guest. It would also lock up the embedder if the guest crashes. I had a
> similar
> > approach to this 4 years ago, and Darin and Rob asked me to drop it.
> 
> The exact deadlock situation with the dialog API is this.
> 
> 1. The guest sends out a FrameHostMsg_RunJavaScriptMessage.
> 2. A scroll begins on the guest in the embedder before the embedder handles
the
> message above, and starts waiting on scroll response from the guest.
> 3. DEADLOCK.
> 
> There are likely other deadlocks around plugin support. This is a fundamental
> issue of the web platform, modal dialogs are bad...

Thanks for the clarification ... that certainly is an undesirable scenario.

Unfortunately the ideas we've explored to date to allow asynchronous scroll
bubbling all have challenges that appear to require major changes in the current
messaging system. With the re-design we'll need to do for OOPIF scrolling, it
seems unattractive to do a big overhaul now that would be throw away work when
the OOPIF changes land.

I'll continue to see if I can devise something both safe and lightweight for the
interim; it might be good if we arranged a time to chat about this (possibly
early next week?)

[wjmaclean, 2015-09-15 20:48:43]

On 2015/08/11 13:05:23, wjmaclean wrote:
> On 2015/08/11 12:41:59, Fady Samuel wrote:
> > On 2015/08/11 12:31:39, Fady Samuel wrote:
> > > On 2015/08/11 07:56:40, wjmaclean (OOO Aug 4-7) wrote:
> > > > On 2015/08/10 14:58:19, Fady Samuel wrote:
> > > > > This approach will not work. It will result in potential deadlocks.
The
> > > guest
> > > > > can block on the embedder (dialog API). If the embedder can also block
> on
> > > the
> > > > > guest, then we introduce the risk of deadlocks. Scroll bubbling must
be
> > > async.
> > > > 
> > > > Can you elaborate a bit on how the deadlocks would happen? You mention
> > dialog
> > > > API ... would the deadlock occur when a dialog in the embedder is
> triggered
> > on
> > > > some event that the guest is also expected to handle?
> > > > 
> > > > It would help me to rethink this if you could suggest some specific
> examples
> > > > (that I could eventually use as test cases).
> > > 
> > > It would deadlock when a dialog (alert/confirm/prompt) is initiated from
the
> > > guest. It would also lock up the embedder if the guest crashes. I had a
> > similar
> > > approach to this 4 years ago, and Darin and Rob asked me to drop it.
> > 
> > The exact deadlock situation with the dialog API is this.
> > 
> > 1. The guest sends out a FrameHostMsg_RunJavaScriptMessage.
> > 2. A scroll begins on the guest in the embedder before the embedder handles
> the
> > message above, and starts waiting on scroll response from the guest.
> > 3. DEADLOCK.
> > 
> > There are likely other deadlocks around plugin support. This is a
fundamental
> > issue of the web platform, modal dialogs are bad...
> 
> Thanks for the clarification ... that certainly is an undesirable scenario.
> 
> Unfortunately the ideas we've explored to date to allow asynchronous scroll
> bubbling all have challenges that appear to require major changes in the
current
> messaging system. With the re-design we'll need to do for OOPIF scrolling, it
> seems unattractive to do a big overhaul now that would be throw away work when
> the OOPIF changes land.
> 
> I'll continue to see if I can devise something both safe and lightweight for
the
> interim; it might be good if we arranged a time to chat about this (possibly
> early next week?)

Closing this issue as the approach is obsolete.