Cc'ing Devs from  Issue 574343  for further investigation and debugging.

From your description it sound more like a problem with background tab throttling.  A trace would be super useful in diagnosing this:

1. Navigate to about:tracing
2. Click Record
3. Click Manually select settings
4. In the right hand column (Disabled by Default Categories) check renderer.scheduler
5. Click record again.  About 5-10s should be enough data.

Please be aware the trace will contain things like urls for all the open tabs, so if there's anything sensitive I'd suggest closing all but the minimum number of tabs needed to illustrate the bug.


RE Task blocking

Task blocking can only happen while we are expecting a user gesture.  The current logic is super simple, we expect a user gesture for 2s after the use has scrolled.  Neither M50 or M51 have task blocking enabled.




 

Unfortunately, I cannot reproduce the issue. We know that some of our clients experience it, so we extended the debug logs to find when it appears.

We mark every request with a unique ID to trace it within our backend system, and we also started to log information about when the client switches the tab.

For some clients, we found that the request from 1s timer stops, but these from the 15s timer continue to work. Around 60% of these clients, have a tab change before the problem appears and for the rest of them did not (we started to log on visibility change events to find if background tabs cause the problem)

One of our clients reproduced the problem and we asked him to save a trace info. But this was made when the issue was already reproduced. I attach the trace data ( there was a 3 open tabs, our app is live.trader.bg )

We didn't know when the bug will appear so we cannot start tracing at the time the problem appears.

We observe logs for the third day and the problem exists only under Blink browser (Chrome 50/51, Yandex 16, Opera 38)

Deleted: trace_live.trader.bg.json.gz 5.0 MB

trace_live.trader.bg.json.gz 5.0 MB Download

Hello,

We think we might have the same issue with you.
Reported the issue in https://bugs.chromium.org/p/chromium/issues/detail?id=625041.
Could you please have a look as well? Thanks.

Regards,
Helen

I attached a trace file which reproduce the issue in our website for your check in https://bugs.chromium.org/p/chromium/issues/detail?id=625041. Could you please help to have a check as well? Thanks a lot!

The issue is still reproducible from some of our clients. Any idea what cause the problem or what can we do to fix it?

Is there a repro you can share?  I've not been able to reproduce it myself.

No, I don't know how to reproduce the issue. I just observe from backend logs that it appears only for clients that uses Chrome, Opera or Yandex. I can get some debug data but only when the issue appears. I don't know what could be useful and how to get it.

It's strange that a core functionality like setInterval is broken and it's not easy to understand whats going wrong.

Some of our users are reporting the same issue! It took a while to figure out what exactly happened on their machines. To sort it out we checked if we - at any time - clear the interval by ourselves. We can definitely eliminate this option. The interval stops for no apparent reason within 1-3 minutes using our web-application.

Unfortunately the bug does not appear on simpler Test-pages.
For instance we created one main interval and add random intervals that got cleared after being executed once. (https://jsfiddle.net/h4jue530/)

One users setting:
Client: HexChat 2.12.1 • OS: Microsoft Windows 10 Home (x64) • CPU: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz (2.40GHz) • Memory: 7.9 GiB Total (3.4 GiB Free) • Storage: 52.8 GiB / 455.6 GiB (402.8 GiB Free) • VGA: Intel(R) HD Graphics Family
Google Chrome Version 51.0.2704.103 m (64-bit)

Another user can switch between Linux and Windows and has the problem on both OS.

It's not easy to reproduce it. I can see that only 10% of our clients experience the problem. We also double checked if the interval is cleared by ourselves. If the problem was in our code, then it would be reproducible under all browsers not only Blink related.

You can see the discuss in another issue from comment #4. There are more details about the problem.

Reproducing this bug is proving to be very difficult.  Thanks for the js fiddle, I'll see if I can reproduce it with that. 

Out of curiosity is there any reason to think this might be more of a problem with lower end machines?

The fiddle was actually not reproducing the issue. I was just trying to keep you up with the research we did. It also looks that - in our case - only the first interval gets cleared by random. However we cannot nail it down, if that is really the case.

|Out of curiosity is there any reason to think this might be more of a problem with lower end machines?
We have this user who have Linux and Windows on the same machine. He encounters this bug on both OS.

We did some tests to bring the interval under load (one-second-while-loop). No problem on the affected users machines. Tab throttling can be excluded. This bug occurs even when the user is staying within the application without switching tabs. New intervals can also be started and seem to be executed. We also asked them to run the application in incognito-mode to exclude any extensions interferences. No luck there.

We have videos posted by the users where there is no reasonable action they make which could lead to a clue. But it seems not to occur when they do nothing at all. Interaction seems to be required. At least mouse-move. We have some technical advanced users that understand that bug finding is hard and try to be as precise as possible.

We have also added an option in our app to (re-)start the interval again executing the same code (Custom application console). It then runs again for 1-3 minutes being stopped again for no apparent reason. So it is not necessarily the first interval that breaks. We have overridden clearInterval to print out the ids. The broken one is never been cleared by our code.

Btw, no exceptions are are thrown within the setInterval handler. (I know that this shouldn't clear the interval anyway, just letting you know).

We are not using any third party libraries, so it's not related to the dojoX/Timer lib.

Does this bug still occur in M52 or is it M51 only?

My suspicion is this is somehow related to Oilpan and in particular the code in TimerBase::runInternal() which checks if the timer object is about to be swept from the oilpan heap.

To be clear I don't have any proof for that, despite looking. 

I can see that some users with M52 also experience the problem. No logs from M53, but the number of users with these versions are too low to proof that the problem is fixed.

I'm reasonably certain this has the same root cause as  crbug.com/625041 .

Maybe there's something else going on here if this bug affects M52. The repro I have for setInterval stopping only works in M51. M52 and M53 don't have that specific bug.

With version 52 our users report that everything works now as expected. Thank you!

Oh OK it was the same bug then.  Thanks for letting us know, I'll close this issue now.