Tried testing the issue on chrome version# 71.0.3578.98 using Mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://jsfiddle.net/coLstepy/
2) Clicked on 'Flash' button, able to see animation text
3) Increased the "Number of Frames" value and clicked on 'Flash' button, able to see animation text

@Reporter: Please find the attached screencast for your reference and provide your feedback on it which help in further triaging the issue is better way.

Thanks!

Deleted: 919408.mp4 939 KB

	919408.mp4 939 KB View Download

Oh sorry oO, I didn't linked to the correct fiddle...

Here it is [1], basically the same, but more minimal, and better exposes the issue which is reproducible only when dealing with a single frame.

So #4 your screencast coincidentally exposes what I describe, but I fear it's less because you actually experienced the issue, than your screencast is not recording the screen at 60FPS.

Comments in the new fiddle should help better understand the issue, but basically sometimes (randomly, it might be ~ 1/20), the single frame that should have been painted is not painted. 

I don't know which Component is really responsible for it, from here I'd say it's something in-between the timing and the painting, like some painting optimization that says too early to discard a paint, but still does execute AnimationFrame callbacks or alike. But I don't have the tools that would allow me to further debug the issue.

Also, I do experience it on 71.0.3578.98 (Official Build) (64-bit) on osX and on  73.0.3667.0 (Official Build) canary (64-bit) still on osX.  
However, I don't think it is a regression, I tried on Version 47.0.2509.0 (64-bit) from bisect-builds and found the same buggy behavior.
Seeing I can repro in Safari makes me think it can even be a relic from Webkit times.



[1][http://jsfiddle.net/v8tb19p2/]

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Digging a bit more, I found another weird pattern... and finally a workaround...

While the correlation with the issue is not full, I think I found that requested frames from a mouse event are executed directly instead of waiting for the next frame as the specs require.

This causes the first call to be executed in the same frame as the clearing one.

The strange thing though is that it doesn't happen every time (~95% of times).

Also, I miss solid tools to test all this, so I don't have strong confidence in my hand-made event-loop counter...

Anyway, here is an updated test case [1], which will try to report how many event-loop iterations occurred between the initial call, the first rAF execution and the last one. I found out that on my computer, 95% of time `nb_of_loops_between_call_and_start` reports `0`. 
I also found that when the paint is missing, `nb_of_loops_between_start_and_end` is below 20.

Note that I also did try [2] to call rAF from inside each event loop iterations between one frame, and there, all the frames got executed correctly at the same time.
So I would actually suspect something between mouse events and requestAnimationFrame, but once again, I really don't have the tools to test correctly...

And while writing this comment I realized that keeping an active requestAnimationFrame loop active [3] does fix all the issues: non more paint trouble, and time between call and start has a better distribution.

So if I had to formulate a final guess, I'd say there is something in rAF that does check if the stack of rAF callbacks are empty and if so execute the callback directly.

[1][https://jsfiddle.net/v8tb19p2/2/]
[2][https://jsfiddle.net/uxp3oht2/]
[3][https://jsfiddle.net/v8tb19p2/3/]