Pass allow_delayed_resize in CompositorFrameMetadata

Pass allow_delayed_resize in CompositorFrameMetadata

Delayed resize on top-control show/hide may cause inconsistency
between the compositor and blink about the position of bottom-
fixed-position elements. If touch occurs during the inconsistency,
the touch may be sent to the wrong element.

Now pass allow_delayed_resize in CompositorFrameMetadata. It's false
if there is any bottom-fixed-position element in the page. The Java
side FullScreenManager won't delay resize if |!allow_delayed_resize|.

BUG=334779

[Xianzhu, 2014-01-22 00:05:17]

Patch Set 2 simpifies Patch Set 1 which was an experiment of passing
end-of-fling in CompositorFrameMetadata. Now we have used another way to pass
end-of-fling, and this patch is to pass allow_delayed_resize only.

I'm not sure if we should fix crbug.com/334779 with this change. For a page with
complex layout fixing the bug may cause janky flinging after top-control
animation because of the cost of resize. wdyt?

[aelias_OOO_until_Jul13, 2014-01-22 03:57:16]

Hmm, it doesn't feel right for the browser compositor to have to know whether a
bottom fixed pos element exists.  That's fundamentally none of its business.

Would it work to instead, for example, delay tap events until top controls
animation or fling is complete?  (We already suppress taps that happen during
fling if I recall correctly.)

[Xianzhu, 2014-01-22 20:46:01]

On 2014/01/22 03:57:16, aelias wrote:
> Hmm, it doesn't feel right for the browser compositor to have to know whether
a
> bottom fixed pos element exists.  That's fundamentally none of its business.
> 
> Would it work to instead, for example, delay tap events until top controls
> animation or fling is complete?  (We already suppress taps that happen during
> fling if I recall correctly.)

Delaying tap events only seems not enough. Original touch events and all other
position-related events also might be wrong-targeted.

As current fling will be canceled on new touches, we could resolve the bug by
forcing resize on touches, but this would degrade performance during multiple
quick up and down flings.

The root cause of the inconsistency seems that the compositor calculates the
viewport size by itself, and it depends on the browser to get blink's viewport
size synchronized. Perhaps we can let the compositor know blink's viewport size
and adjust the position of the event if it hit any bottom fixed pos element
(compositor's position). Actually we already send the blink viewport size (first
parameter of RenderWidgetCompositor::SetViewportSize()) to compositor but for
now the parameter is ignored.

[Xianzhu, 2014-01-22 22:44:18]

On 2014/01/22 20:46:01, Xianzhu wrote:
> Perhaps we can let the compositor know blink's viewport size
> and adjust the position of the event if it hit any bottom fixed pos element
> (compositor's position).

Just noticed the above won't work. For example, a bottom fixed pos element E, in
blink its position is EP and in compositor its position is EP' (where the user
sees E). We'll encounter problem when a touch event is in EP (where shows not E
but some background layer of E) but not in EP'.