This seems to be a problem with the zoom level. I can't reproduce the bug with 100% zoom, but as soon as I zoom in (or out) chrome starts freaking out. When you were testing the bug, was your browser tab zoomed in? See screen recording for reference. 

Deleted: 2018-10-11_15-40-20.mp4 7.6 MB

	2018-10-11_15-40-20.mp4 7.6 MB View Download

+1, looks like you need to change the browser zoom to reproduce the issue.

Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome reported version #69.0.3497.100 and latest canary #71.0.3577.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Deleted: 894412.mp4 720 KB

	894412.mp4 720 KB View Download

Thanks for your answers.

Since my screen is 4K, in the display settings, it is set to scale 250%, hence I see the problem even at regular zoom. If I zoom out up to 40%, then it works fine, since it's equivalent to no zoom. I guess most people with Full HD or 4K displays experience this issue with no zoom.

Thanks !

I can reproduce it as well. If I move my mouse to the point and stay there everything works fine. However the issue manifests itself if I move my cursor slightly around the edges. Also  when I see the jump I also see two animations in animation panel. 


I wonder if the changes in the stroke-width which is changing the shape is going to trigger the transition again in the middle as the first transition itself can cause the hover state to change. I will see if I can create a smaller repro.

Here is the minimal repro case: https://jsbin.com/vibasep/edit?html,output

OK, so I think the core issue is that when strokeWidth is being animated and when page is zoomed, then somehow it is incorrectly scaled. The scaling goes away once the animation is complete. 

So there is a jump artifact at the beginning and end of the animations. You can see this by doing  "document.querySelector('svg').classList.toggle('enlarge')" in console while browser is zoomed. See attached gif.

I think this issue combined with :hover animation can cause very odd artifacts where the element seems to jump around.
 

Deleted: strokeWidthIssue.gif 351 KB

	strokeWidthIssue.gif 351 KB View Download

pdr@: Are you aware of any SVG scaling issues that might be related.

A quick search turned up issue 848748 which affects length but I wonder if it may be related.

The 'stroke-width' property is special in that it is kept "unzoomed" in computed style (see LengthPropertyFunctions::IsZoomedLength in the animation code.) Presumably that is messed up at some point and zoom ends up being applied when it shouldn't.

fs@: Thanks! that is going to be helpful narrowing down that root cause.

It looks like the animations code is aware of the lack of zooming:

Unzoomed:
[1:1:1024/104608.566521:INFO:length_property_functions.cc(298)] Returning 10, IsZoomedLength ? 0
[1:1:1024/104608.566738:INFO:length_property_functions.cc(298)] Returning 15, IsZoomedLength ? 0

Zoomed:
[1:1:1024/104630.756138:INFO:length_property_functions.cc(298)] Returning 10, IsZoomedLength ? 0
[1:1:1024/104630.756553:INFO:length_property_functions.cc(298)] Returning 15, IsZoomedLength ? 0

Tracking what the code is doing with the value from the animation now.

Ah, LengthInterpolationFunctions::CreateLength doesn't account for zoom. Fixing.

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

commit a14d455b3690e2370f1e7d08ace0a248052276ef
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Thu Oct 25 21:49:57 2018

Fix animation of stroke-width with non-100% zoom level

Most of the animations code knows to apply zoom properly for
stroke-width (which is zoom agnostic), but
CSSLengthInterpolationType::ApplyStandardPropertyValue was passing the
default CSSToLengthConversionData without setting the effective zoom
level. This CL fixes that.

Bug:  894412 
Change-Id: Ieaf57a794cc1f94b017730b5918e410a86a3fa5f
Reviewed-on: https://chromium-review.googlesource.com/c/1297748
Reviewed-by: Yi Gu <yigu@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602873}
[add] https://crrev.com/a14d455b3690e2370f1e7d08ace0a248052276ef/third_party/WebKit/LayoutTests/animations/svg/stroke-width-zoom-factor.html
[modify] https://crrev.com/a14d455b3690e2370f1e7d08ace0a248052276ef/third_party/blink/renderer/core/animation/css_length_interpolation_type.cc

Thanks for the quick resolution ! When do you think it will be shipped on production ?

Hi Michael,

The fix landed in Chrome 72.0.3592.0, which is currently canary for most platforms (Linux excepting). Chrome releases roughly every 6 weeks and the current stable is M70, so it will be available in stable in ~12 weeks.

Because it is not a regression nor a serious issue, we won't be cherry-picking it to M71 or M70.

Thanks,
Stephen