aw: Fix lost invalidate while playing video

aw: Fix lost invalidate while playing video

BrowserViewRenderer::block_invalidates_ needs to be unset immediately
after draw. Posting the unset to UI thread could imply that it comes
after the fallback tick, which can cause an invalidate to be dropped.

This is especially bad for VideoLayer since the fallback tick does not
advance video frames, which means the video could be stuck forever.

Fix by unsetting block_invalidates_ and cancelling fallback tick
immediately, but only post back to get the invalidate.

Internal bug b/14643271

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

[Ignacio Solla, 2014-05-12 10:39:57]

lgtm

[boliu, 2014-05-12 14:02:39]

+mkosiba for commiter stamp

[mkosiba (inactive), 2014-05-12 14:29:51]

https://codereview.chromium.org/271163002/diff/20001/android_webview/browser/...
File android_webview/browser/browser_view_renderer.cc (right):

https://codereview.chromium.org/271163002/diff/20001/android_webview/browser/...
android_webview/browser/browser_view_renderer.cc:719: fallback_tick_.Cancel();
this doesn't look threadsafe:

from base/cancellable_callback.h

"CancelableCallback objects must be created on, posted to, cancelled on, and
destroyed on the same thread."

[boliu, 2014-05-12 15:34:49]

https://codereview.chromium.org/271163002/diff/20001/android_webview/browser/...
File android_webview/browser/browser_view_renderer.cc (right):

https://codereview.chromium.org/271163002/diff/20001/android_webview/browser/...
android_webview/browser/browser_view_renderer.cc:719: fallback_tick_.Cancel();
On 2014/05/12 14:29:51, mkosiba wrote:
> this doesn't look threadsafe:
> 
> from base/cancellable_callback.h
> 
> "CancelableCallback objects must be created on, posted to, cancelled on, and
> destroyed on the same thread."

Hmm, good point. There is nothing protecting running the callback.

Moved to UI thread instead. Cancelling shouldn't matter other than a few
unnecessary fallback ticks.

[boliu, 2014-05-12 16:25:21]

PTAL btw..

[boliu, 2014-05-13 05:54:45]

Please cq this if you think it's good to go

[mkosiba (inactive), 2014-05-13 08:43:29]

lgtm

[mkosiba (inactive), 2014-05-13 08:43:32]

The CQ bit was checked by mkosiba@chromium.org

[commit-bot: I haz the power, 2014-05-13 08:43:56]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/boliu@chromium.org/271163002/40001

[commit-bot: I haz the power, 2014-05-13 12:07:10]

FYI, CQ is re-trying this CL (attempt #1).
Please consider checking whether the failures are real,
and report flakes to chrome-troopers@google.com.
The failing builders are:
  android_dbg_triggered_tests on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_dbg_triggered...)
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)

[boliu, 2014-05-13 13:46:02]

The CQ bit was unchecked by boliu@chromium.org

[boliu, 2014-05-13 13:48:21]

The CQ bit was checked by boliu@chromium.org

[commit-bot: I haz the power, 2014-05-13 13:48:48]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/boliu@chromium.org/271163002/40001

[commit-bot: I haz the power, 2014-05-13 15:17:34]

Change committed as 270101