Able to reproduce the issue on windows 10,Mac 10.13.3 & debian using chrome stable-66.0.3359.181 & latest Canary-68.0.3436.0 as per above svg.html. Same issue observed from M60. As it is non regression issue,marking it as Untriaged to get it addressed from dev team.

Please find the attached screencast of chrome & mozilla for reference.

Thanks..!

Deleted: 845375-chrome firefox.mp4 394 KB

	845375-chrome firefox.mp4 394 KB View Download

hi,I change the path of the <animateMotion> element like the attachment, and it works as expected in chrome.
Is there has any rule to avoid this bug?

Deleted: svg-2.html 917 bytes

svg-2.html 917 bytes View Download

That's odd... but based on the two examples, it would seem best to avoid degeneracies (the first control point of the bezier being the same as the initial point in svg.html.) Not entirely sure that's cause of the issue of course. Needs more investigation.

I make another 2 demos to test your guess（the first control point of the bezier being the same as the initial point in svg.html.).But unfortunately, your guess seems wrong.the svg-3 file has diffrent first control point and the initial point, but it works wrong in chrome. And the svg-4 file has same first control point and the initial point, but it works as expecte.

Deleted: svg-4.html 945 bytes

svg-4.html 945 bytes View Download

Deleted: svg-3.html 978 bytes

svg-3.html 978 bytes View Download

What't more,I deleted the number after the decimal point in svg-3 and svg-4 files，and it works as your guess。If the first control point of the bezier being the same as the initial point, it works wrong.

Deleted: svg-5.html 936 bytes

svg-5.html 936 bytes View Download

Deleted: svg-6.html 932 bytes

svg-6.html 932 bytes View Download

At closer inspection, it looks like it's caused by a numerical issue, so probably not easy to make a general workaround for I'm afraid.

I will use integers and keep the first control point of the bezier being the diffrent as the initial point in my project, and continue to observe this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/608088846ca78725c5817443a1eaf917c72d0b5a

commit 608088846ca78725c5817443a1eaf917c72d0b5a
Author: Fredrik Söderquist <fs@opera.com>
Date: Wed May 23 11:04:10 2018

Use consistently computed lengths when finding relevant contour

In CalculatePointAndNormalOnPath, compute the accumulated length of the
contours and compare against the passed in (now unmodified) |length|, to
increase the chances of comparing similarly computed length with each
other. |length| is often, directly or indirectly, derived from the
computed length of the Path (i.e using Path::length().)

Bug:  845375 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ibda61dd29921f41e0b294edde31ddb21ebbefd08
Reviewed-on: https://chromium-review.googlesource.com/1069071
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561032}
[modify] https://crrev.com/608088846ca78725c5817443a1eaf917c72d0b5a/third_party/blink/renderer/platform/BUILD.gn
[modify] https://crrev.com/608088846ca78725c5817443a1eaf917c72d0b5a/third_party/blink/renderer/platform/graphics/path.cc
[add] https://crrev.com/608088846ca78725c5817443a1eaf917c72d0b5a/third_party/blink/renderer/platform/graphics/path_test.cc