*** IMPORTANT ***

Please test the issue at http://opentarget.org rather than the URL provided above.

If I find a workaround for my website I will apply it and you won't be able to observe the issue there anymore.

I meant http://opentarget.org/en/info

For fuck's sake, will the day ever come when this stupid bugtracker will allow users to edit their own reports and comments?

I can SOMETIMES (randomly) reproduce the issue on a minimal example here:

http://jsbin.com/hehabep/edit?html,output

In this example, the image of the cat is supposed to oscillate shrinking and growing back and forth. (ignore the links at the bottom). It follows a sinewave-like function, and when the sine is below zero, the scaleX transform stays at zero (that's expected).

Here, in order to reproduce the issue, I right-click on the cat and do "inspect element". Most of the time, the image will remain hidden forever.

By inspecting the element you can see that it's not the case that the animation pauses because you are taking focus away from the content: the style property of the element can be seen and it keeps oscillating.


However, at http://opentarget.org/en/info the issue appears systematically and without opening the Developer Tools, so there's something that triggers the issue that I'm missing, which happens systematically (or almost) on my website without touching the developer tools, and only randomly in the example only when inspecting elements.

Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome reported version #67.0.3396.99 but the same is not reproducible in the latest canary #69.0.3486.0.

Reverse Bisect Information:
=====================
Good build: 69.0.3465.0
Bad Build : 69.0.3464.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/bfcc445d6f5eff3faa5de0cc239f72dd11f5eee7..efddbaa1da8640c7556477a5040462ddd6f2bb69

From the above change log suspecting below change
Change-Id: Ie24af4de933336e888065e993e473ab8ed4711a4
Reviewed-on: https://chromium-review.googlesource.com/1105298

wangxianzhu@ - Could you please check and merge the fix to M-68 if it is a valid candidate.
Note: Adding stable blocker for M-68 as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

I don't observe the issue on beta 68.0.3440.42 (Ubuntu).
Also I have tested Chromium 66.0.3359.181 and it works as expected too.

So:
66.0.3359.181 good
67.0.3396.99 bad
68.0.3440.42 good
69.0.3464.0 bad
69.0.3465.0 good

?

Since it works on beta M68 and canary M69 there is nothing to do, closing this
bug.

Bug reporter: you have violated the code of conduct of Chromium with your language. I see you
have done it on at least one other bug report as well. We appreciate the reports but cannot
tolerate aggressive or disrespectful language.

https://chromium.googlesource.com/chromium/src/+/master/CODE_OF_CONDUCT.md

Please do not do it again or you will be banned from the project.

> Since it works on beta M68 and canary M69 there is nothing to do

It seems to me that there *is* something to do.
Since the bug regressed again and was fixed again between 68 and 69, it should be made sure that the cause is known (that it didn't just fluctuate by chance) so that it is prevented from resurfacing again.

I say this respectfully and unaggressively.

We do know the cause, though I did not mention it here I agree.

The research leading to the patch referenced in comment 7 yielded the root
cause.

Is there a known workaround while I wait for the fixed version of Chrome to be released to the public (and for the user of my affected website to install it)?

Given the extreme seriousness of this issue, which breaks lots of existing websites, shouldn't you speed up the process of releasing the fixed version, or release an urgent update to version 67 with a fix, or whatever??

Users should start to see Chrome 68, with the fix, sometime in the next couple of weeks.

I know, that's an unacceptably long time.

So what about a workaround?

> So what about a workaround?

I mean for those like me who have their website completely f***ed because of this and have some spare time to waste applying a workaround, is there one?

You can work around the issue in Chrome 67 by adding will-change: transform
to the CSS of the element being transformed. This will allocate a composited
layer for it, which for technical reasons will avoid the bug reported here.

Apologies for this regression, and thank you for filing the bug.

Please do not use foul language on Chromium issues, or risk being banned.
See our code of conduct here:

https://chromium.googlesource.com/chromium/src/+/master/CODE_OF_CONDUCT.md