Yes, I actually meant that CSS animation of SVG's stroke-dasharray is not working. Sorry for misleading.

Can you provide a minimal test case that illustrates the problem? This would make it easier to reproduce.

(Extra data point: I could not repro on Linux desktop.)

Try this: https://m.oumy.com/#/test

Also here is couple of screenshots, first is Chrome Beta, second is Chrome Stable.

Deleted: Screenshot_2016-03-02-23-04-49.png 38.3 KB

	Screenshot_2016-03-02-23-04-49.png 38.3 KB View Download

Deleted: Screenshot_2016-03-02-23-05-36.png 36.7 KB

	Screenshot_2016-03-02-23-05-36.png 36.7 KB View Download

Do you reproduce the problem with http://codepen.io/mrrocks/pen/EiplA ? This is an example that I found through Google and is closer to what I meant by minimal test case (although it's still not very minimal).

No, it's not reproducible there. I tested on other examples before posting here. It's only broken on m.oumy.com.

There cannot be more minimal example than that. If I will extract loading implementation from project it may work as those demos on codepen. So it's better test where it doesn't work.

Here is staging env without minification of JS and CSS, if this will help: https://html5.oumy.com:8080/#/test

OK, thanks.

Okay, here is "minimal" demo and it works for me in Beta http://codepen.io/anon/pen/PNqJKe

Do not know what is going on when it's inside m.oumy.com. But works in stable.

Whoops, made a mistake on the labels. Passing this issue over to the test team for confirmation.

Able to repro using Android Chrome 50 (dev).

This does not require animations to repro, this is some weird interaction between <meta name="viewport" content="width=device-width, minimum-scale=1.0"> and SVG layout/paint.

Please bisect on Android using attached minimal test case.

Deleted: test.html 380 bytes

test.html 380 bytes View Download

Deleted: android-incorrect.png 137 KB

	android-incorrect.png 137 KB View Download

Deleted: desktop-correct.png 134 KB

	desktop-correct.png 134 KB View Download

As far as I know, that <meta> tag enables "GPU Rasterization", so might be it.

Looks like the dasharray is not being applied at all. Could be a bug with a circle/oval fast-path.

Just to know.. Is there a chance to have it fixed in Next Android Stable release?

Chrome/WebView/etc are no longer tied to android releases, so that shouldn't be a problem like it was in the past. Sadly, I don't think it's possible to guarantee a specific fix timeframe. As a workaround, it sounds like you can tweak the meta viewport tag though (just remove minimum-scale).

@Cary, would you be able to look at this? It looka like a Ganesh bug.

Oh, I actually meant "before next Chrome Stable release on Android".

Yeah, I understand that it will help, just trying to figure out if I need to do it or not.

Upstream bug: https://bugs.chromium.org/p/skia/issues/detail?id=5082

You are probably looking for a change made after 361277 (known good), but no later than 361299 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/79e75dc188e82f80fbf053694ccf4a0d2ef5ef4b..07ece06c99c9b15c5d2ea779239f856e066c97da

Most likely https://chromium.googlesource.com/skia.git/+/512e437e1e07159a258dd3c5b907576bd1aefc1e.

Brian landed a Ganesh workaround which fixes the issue: https://skia.googlesource.com/skia/+/6266dca7a7a991634d144cbc3a2c6cffefd67454

It would normally ship out in M51, but since it's a regression and the workaround is reasonable we should consider it for merging.

Btw, maybe it's good idea to have tests for it? I do not know how you do them, but if you gave them for painting then test for this issue should there, I think.

We have coverage for dashing in Blink's layout tests, but

1) only a subset of the layout tests are run with GPU rasterization enabled

2) this particular issue only manifests itself with distance-field path rendering, which I'm not sure whether is enabled/supported for all GL impls (so even if dashing tests are run against the GPU backend, chances are the Mesa-based test bots would not catch it)

Skia OTOH has more specialized GPU test bots, so it's a good idea to add a regression test to its suite.

Your change meets the bar and is auto-approved for M50 (branch: 2661)

Great news, thanks for fixing it.

@#23

I see, thanks for explanation. Hope that Skia will have more such tests :-)

Please try to merge your change to M50 branch 2661 ASAP if you think it is a safe merge as we're close to M50 Beta candidate cut for next week. Thank you.

The following revision refers to this bug:
  https://skia.googlesource.com/skia.git/+/dde87ad6d5278661aac6a8eda9e8f43deb255fe2

commit dde87ad6d5278661aac6a8eda9e8f43deb255fe2
Author: fmalita <fmalita@chromium.org>
Date: Tue Mar 15 03:20:11 2016

[M50] Reject dashes from GrAADFR

Cherry-pick of 6266dca7a7a991634d144cbc3a2c6cffefd67454 into chrome/m50.

BUG= chromium:591424 
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1784493004

Review URL: https://codereview.chromium.org/1784493004
NOTREECHECKS=true
NOTRY=true
NOPRESUBMIT=true
TBR=bsalomon@google.com

Review URL: https://codereview.chromium.org/1802863002

[modify] https://crrev.com/dde87ad6d5278661aac6a8eda9e8f43deb255fe2/src/gpu/batches/GrAADistanceFieldPathRenderer.cpp

As per Comment #27, this is already merged to M50. So removing "Merge-Approved-50" label.

This also affects the Google homepage, internal bug at go/591424.

I found a workaround is to use shape-rendering: crispEdges (this avoids the same ganesh codepath as the fix that landed).