Fix overscroll glow when the FIP dialog is active

Fix overscroll glow when the FIP dialog is active

The FIP dialog retains focus even when the user scrolls the contents of a page.
Normally, loss of RenderWidgetHost focus would disable the overscroll effect,
preventing the glow from ever showing when the FIP dialog is open. This patch
address the issue by re-enabling the overscroll effect when gestures are
forwarded to the RenderWidgetHost.

BUG=251031
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207968

[jdduke (slow), 2013-06-21 15:32:29]

PTAL. This is the cleanest way that I've found to handle the issue; the
alternative is all sorts of nasty plumbing up in Java land to figure out when
certain layouts are active and sending down disable signals accordingly. 

aelias: content/browser/renderer_host
joth: content/browser/android

[joth, 2013-06-21 16:39:38]

+sievers - OK I redirect this to you? I'm not really familiar with the
overscroll code flow.

[no sievers, 2013-06-21 17:05:46]

lgtm for owners.

But adding Ted to double-check that it's ok to reenable the glow effect when a
gesture event is sent.
If we had any dialog on top where we do not want a glow, we would never be
sending a gesture event to the view? Is that the assumption?

[jdduke (slow), 2013-06-21 17:25:20]

On 2013/06/21 17:05:46, Daniel Sievers wrote:
> lgtm for owners.
> 
> But adding Ted to double-check that it's ok to reenable the glow effect when a
> gesture event is sent.
> If we had any dialog on top where we do not want a glow, we would never be
> sending a gesture event to the view? Is that the assumption?

Yes, but I'd love for confirmation. 

In short, we want it disabled when 1) Tab or side switching is enabled, or 2)
It's out of view entirely.  Outside of those cases, I would imagine the creation
of overscroll from cc would be the natural limiter for the effect.

As far as I'm aware, gestures will never be sent under (1) or (2), but I could
be wrong?

[Ted C, 2013-06-21 17:44:03]

On 2013/06/21 17:25:20, jdduke wrote:
> On 2013/06/21 17:05:46, Daniel Sievers wrote:
> > lgtm for owners.
> > 
> > But adding Ted to double-check that it's ok to reenable the glow effect when
a
> > gesture event is sent.
> > If we had any dialog on top where we do not want a glow, we would never be
> > sending a gesture event to the view? Is that the assumption?
> 
> Yes, but I'd love for confirmation. 
> 
> In short, we want it disabled when 1) Tab or side switching is enabled, or 2)
> It's out of view entirely.  Outside of those cases, I would imagine the
creation
> of overscroll from cc would be the natural limiter for the effect.
> 
> As far as I'm aware, gestures will never be sent under (1) or (2), but I could
> be wrong?

Those seem like reasonable assumptions to me.  If we were sending gesture events
to the tabs while side swiping or hidden then the content would be moving quite
unexpectedly.

[Ted C, 2013-06-21 17:44:12]

lgtm

https://codereview.chromium.org/17413016/diff/1/content/browser/android/overs...
File content/browser/android/overscroll_glow.cc (right):

https://codereview.chromium.org/17413016/diff/1/content/browser/android/overs...
content/browser/android/overscroll_glow.cc:92: : enabled_(true),
should this default to false?

[jdduke (slow), 2013-06-21 18:16:43]

On 2013/06/21 17:44:12, Ted C wrote:
> lgtm
> 
>
https://codereview.chromium.org/17413016/diff/1/content/browser/android/overs...
> File content/browser/android/overscroll_glow.cc (right):
> 
>
https://codereview.chromium.org/17413016/diff/1/content/browser/android/overs...
> content/browser/android/overscroll_glow.cc:92: : enabled_(true),
> should this default to false?

Normally, yes, but the effect is created on-demand; only an overscroll event
will trigger event creation, in which case you want it enabled.

To make it clear, I'll add an "enabled" argument to the effect creation, so it's
explicit. Thanks.

[commit-bot: I haz the power, 2013-06-21 18:28:43]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jdduke@chromium.org/17413016/10001

[commit-bot: I haz the power, 2013-06-22 00:23:48]

Change committed as 207968