Tested the issue in Android and able to reproduce the issue. 

Steps Followed:
1. Launched the Chrome Browser.
2. Navigate to the URL: https://keithclark.co.uk/labs/css-fps/
3. Tap on any of the tab and try to access the game
4. Observed that Chrome gets hanged.

Chrome versions tested:
64.0.3282.116 Stable/Beta, 65.0.3325.16 (dev) 66.0.3328.0(Canary)

OS:
Android 8.1.0

Android Devices:
Pixel 

Using the per-revision bisect providing the bisect results,
Good Build - 62.0.3197.0 (497604)
Bad Build - 62.0.3198.0 (497674)  

You are looking for a change made after 497614(GOOD), but before 497615(BAD).

CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
https://chromium.googlesource.com/chromium/src/+/9b8fb34db903643b759635086dcf0da90b1e3082

From the CL above, assigning the issue to the owner concerned.

@sunnyps:  Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to owner concerned.

Please navigate to below link for log's and video--
go/chrome-androidlogs/805525

Note: This issue is not observed in Desktop.

Thank you, kindly, for working on this issue. Is there a possibility of getting a fix for this rolled out into the Play store soon?  Also, is there an alteration I can make to my code that will circumvent the problem without destroying functionality?

I have a major project involving a custom animation engine depending on this functionality at it's heart.  I suspect it crashes on transforms with specific numbers.  Certainly, the more transforms involved, the faster it crashes.

Is it possible that avoiding specific numbers in the transform strings could mitigate the problem for the affected versions?

Probably I should mention as well, I haven't tested this on said versions for IOS, so that may be worth looking into.

Anyway, thank you once again!

I found this bug report today... Could it be related?  It refers to CSS-only animations freezing the page for several seconds-- mine is a js ani using an rAF.  If the cause is the same, it would explain why it locks up in a recursive  rAF loop.  I wonder if it is related to the type of transition?  Will test this later today.

https://bugs.chromium.org/p/chromium/issues/detail?id=782002

Update: I thought I had a workaround, however it actually was scaling some elements to 0, thus causing less of a chance to trigger this problem.  I've tried a lot of things, even setting the dynamic transforms via an inline style tag instead of the DOM.  Same problem.

The only pattern I'm finding is every time you set a transform, even in plain css-only animations and transitions, you have a chance of locking up.  If you look at my post on SO, there's some more specific information:  

https://stackoverflow.com/questions/46944373/having-javascript-issues-with-new-chrome-version-62

Could we just revert back this portion of code and push it for version 64 stable?  Looking at the estimated dates of release, it's a long way out before the average user is unaffected.

This is a serious issue for me as it makes my best work completely unusable for production.  Especially since the most important projects are specifically geared toward Chrome on Android because of how well it has worked up until November.

I am sure this affects a lot of developers relying on 3d transforms, as I've seen quite a few similar reports.

If there is anything I can do to help, please do let me know.

These pages used to exercise the 3D modelling quite hard.  Not sure if that is still relevant to the new problems.

This technique is used a lot for html5 games, and FF, Edge, etc. don't have this issue, only Android's version of Chrome 62 and up.  So it's definitely a new and relevent problem.  This functionality is an important part of current standards, and was exemplified by Chrome, as it was the most efficient at using them.

I've gone to the extent of optimizing things down to where only transforms that change are assigned in the RAF loop, any zero-valued transforms are eliminated from the transform string, and the transform-strings are only assigned at a specific frame-rate, making my algorithm very much more efficient and performant than the old shotgun assign-everything-that-moves methodology.  Even works smooth on FF mobile, and uses little battery, almost no extra heat from the gpu etc.  Even at 15fps, as monitored in Dev Tools, it will crash on affected versions, often within 5 to 30 seconds, even just spinning a div in CSS-3D-space.  So something is definitely wrong.

I am wondering if it may have to do with the compiling process for the Android versions.  If the source code is the same, it's the only thing that sticks out in my mind that is different.  Maybe even compiler options given at build-time?

At any rate, Chrome of all browsers should be able to withstand it.  I have a whole VR/Anaglyph 3D world without any optimizations that runs smooth on non-broken versions, even with doubling all the elements and using blend-modes and filters to do the anaglyph in full-screen with two frames.

I forgot to mention, it also affects transforms given via style tags or css sheet.  If it's basically random, with a small chance each time, this is not good for anybody, and could explain some other bug reports involving Chrome browser freezing or crashing on android.

I have the same issue on my website http://lorenz.virtualcolossus.co.uk/LorenzSZ/ which also uses css transforms to rotate the cipher wheels. Issues with random lockups when moving wheels on various Android devices. 

So far though, have yet to see a lock up on current versions of Dev - 66.0.3352.3 or on Canary - 66.0.3354.0

Hi, Martin.  Good to see someone else post on this issue.  Would love it if more people showed this is a serious flaw.  If I understand correctly, they are targeting 66 stable release for the fix, so maybe that parts done and they haven't updated the ticket?  Anyway, it also affects style-sheets, as I made a test engine that set the stransforms via adding them to an inline style tag instead of directly to the elements dom.  At this point all I can do is wait for 66 stable for my users, and hope it works.

Yes, that's how I read it, 66 for stable release. I was very pleased to find your bug report as it's pretty much a show stopper for my simulation on most Android/Chrome platforms since the new year. I spent a while trying to work out what I'd broken before finding this! I have tried your site on Canary too and have yet to see a lock up - fingers crossed they have this fixed now.

That is soo good to hear.  Just hope they push it soon.  From what I've read, it looks like still a couple months out, but in this case I would _gladly_ be wrong.  Martin, you have my curiosity, what is your sim project about?  If you wish elaborate outside this ticket, you can tag me at my gmail address, jdmayfield88@gmail.com .

I have just updated to v65.0.3325.109 and so far, have yet to see a lock up on my page! I'm starting to be hopeful that this issue has been resolved. Will keep watch to see if problems reoccur. Interested to hear if jdmayfield88 also sees resolution.

It's likely this was fixed by https://chromium-review.googlesource.com/c/chromium/src/+/887968

The symptoms are similar to what we saw in  issue 798400 . The above fix is in M65.

WontFix because bug can't be reproduced any more. Please let us know if any of you is able to reproduce this and I'll reopen the issue.

Thank you, all appears good - I appreciate your work on this issue.