Just reverted one of my phones to version 39 (2237560-arm) which I'm guessing is what the phone came with and pauseTimers() worked just fine. Can you please tell me when this started being an issue? 

Thanks.

dunno, but that's not supposed to happen..

do you have a tiny app I could play with?

 Issue 617951  has been merged into this issue.

I'll make one really quick. 

I'm attaching the sample project. And figured out when it happens. If I call onPause() on the webview then pauseTimers() doesn't work. Doesn't matter if I call it first or second. 

Run the project, open chrome for debugging and look at the console, then press pause. 

Deleted: WebViewTimers.zip 20.2 MB

WebViewTimers.zip 20.2 MB Download

Looks like this is broken in 52.0.2743.41 (current beta), but 51.0.2704.81 (current stable) is ok.

And looking at the beta behavior, when webview is paused, timer appears to be throttled, that it fires every two seconds. My guess is that this is chrome changing its policy of how/when js timers should be throttled, but just ignored the state of pauseTimers, which is definitely not ok

fwiw console logs by default are posted to logcat, so grepping logcat imo is a bit easier than looking at devtools

Bisected to between 2730 and 2733. missed two builds in between :/

bisected to https://codereview.chromium.org/1958283005

webview.onPause maps roughly to RenderView becoming hidden
webview.pauseTimers maps to ViewMsg_SetWebKitSharedTimersSuspended

so looks like when when RenderView is hidden and timer is suspended, somehow the suspend state got ignored, and js timers only got throttled? Haven't actually read the CL yet

Yeah, that CL added new enable/disable calls when task queue is throttled, which basically overrides the actual is_enabled policy set by SetWebKitSharedTimersSuspended set only once

it's not really clear to me what the correct fix should be, so will wait for alexclarke to be back

Actually, that says ignore the "is_enabled" part of the policy if task queue is throttled: https://codereview.chromium.org/1958283005/diff/40001/components/scheduler/renderer/renderer_scheduler_impl.cc#newcode847

which kinda breaks the whole is_enabled thing..

trunk code looks a bit different now though

I'll take a look.

I think I see what's happened here.  The code in WebFrameSchedulerImpl::setPageVisible is probably getting called for the backgrounded tab and it's making the timers throttled.   That's conflicting with this snippet from RendererSchedulerImpl::UpdatePolicyLocked which tries to make sure suspended task queues are not throttled. 

if (MainThreadOnly().timer_queue_suspend_count != 0 ||
    MainThreadOnly().timer_queue_suspended_when_backgrounded) {
  new_policy.timer_queue_policy.is_enabled = false;
  new_policy.timer_queue_policy.time_domain_type = TimeDomainType::REAL;
}

I think we can fix this but I'll have to talk to Sami about what the best solution is.

Actually I think this might be fixed already.  Can you try again with a build that includes https://codereview.chromium.org/2028433004?

Yep that fixed it. Please merge to m52

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/26c1102c976aeb0ae91bed0d3f7f7abd92a41e20

commit 26c1102c976aeb0ae91bed0d3f7f7abd92a41e20
Author: alexclarke <alexclarke@chromium.org>
Date: Thu Jun 23 16:02:04 2016

Add a few extra tests for throttling corner cases

While investigating  crbug.com/620857  I noticed we were lacking
tests for some corner cases of throttling and timer suspension.

BUG= 620857 

Review-Url: https://codereview.chromium.org/2081663002
Cr-Commit-Position: refs/heads/master@{#401618}

[modify] https://crrev.com/26c1102c976aeb0ae91bed0d3f7f7abd92a41e20/components/scheduler/renderer/renderer_scheduler_impl_unittest.cc
[modify] https://crrev.com/26c1102c976aeb0ae91bed0d3f7f7abd92a41e20/components/scheduler/renderer/throttling_helper.h
[modify] https://crrev.com/26c1102c976aeb0ae91bed0d3f7f7abd92a41e20/components/scheduler/renderer/throttling_helper_unittest.cc