sorry, jsfiddle is so buggy...

actually, those lines fail:
<use xlink:href="#желтый"/>
<use xlink:href="#%D0%B7%D0%B5%D0%BB%D0%B5%D0%BD%D1%8B%D0%B9"/>

Apparently my FF 58 disagree with yours, because it shows all three circle =). Also, the way I'm reading the spec, the fragment referencing the yellow circle would get percent encoded, and thus given percent decoding when using it, it would still point to the expected element?

Firefox 58 shows three circles in jsfiddle, but only two circles when loading a local file:///R:/test.html
As for the spec, I don't know if the browser should translate #желтый into %-encoded ASCII automatically.

Ok, that makes sense I suppose - presumably adding a <meta charset="utf-8"> or similar will result in all three circles being rendered in the file: case.

i updated the testcase. according to the comment #2, the link should not work in the Chrome 63, but it works. i think <a href> and <use xlink:href> behavior must be identical. and desirable with automatic encoding.

Tested the issue on chrome Stable #62.0.3202.75,Beta #63.0.3239.18 & Canary 64.0.3253.0 on Windows-7 and was able to reproduce the issue.

This is a Non-Regression issue since seeing this from M50 #50.0.2624.0, 

Note : Observed different behaviors from M-50 to M-64 and able to reproduce the issue in MAC 10.12.6 and Linux Ubuntu 14.04.Please find the screen shot for reference.

Thank you.

Deleted: 779420.PNG 282 KB

	779420.PNG 282 KB View Download

#6, yep, with <meta charset="utf-8"> all three circles are seen in FF58. I've removed my comments #2 and #3 as no longer pertinent.

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

commit 7fed5aeb041c935425adb69333bdf610bef896ee
Author: Fredrik Söderquist <fs@opera.com>
Date: Tue Oct 31 19:07:17 2017

Percent-decode fragments before using them for SVG references

We were using the "raw" form of the fragment, meaning that any percent-
encoded fragments would not resolve correctly.

Bug:  779420 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ic091e775589fd59d25ad1878115f2ad2593bc733
Reviewed-on: https://chromium-review.googlesource.com/746885
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#512895}
[add] https://crrev.com/7fed5aeb041c935425adb69333bdf610bef896ee/third_party/WebKit/LayoutTests/svg/custom/fill-url-percent-encoding-expected.html
[add] https://crrev.com/7fed5aeb041c935425adb69333bdf610bef896ee/third_party/WebKit/LayoutTests/svg/custom/fill-url-percent-encoding.html
[add] https://crrev.com/7fed5aeb041c935425adb69333bdf610bef896ee/third_party/WebKit/LayoutTests/svg/custom/use-href-percent-encoding-expected.html
[add] https://crrev.com/7fed5aeb041c935425adb69333bdf610bef896ee/third_party/WebKit/LayoutTests/svg/custom/use-href-percent-encoding.html
[modify] https://crrev.com/7fed5aeb041c935425adb69333bdf610bef896ee/third_party/WebKit/Source/core/svg/SVGURIReference.cpp
[modify] https://crrev.com/7fed5aeb041c935425adb69333bdf610bef896ee/third_party/WebKit/Source/core/svg/SVGUseElement.cpp

 Issue 792848  has been merged into this issue.

should we consider this for a re-roll of M63? Code change looks trivial enough and had sufficient baketime

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

M63 version 63.0.3239.84 has been out since 12/06/17. Do we have any report this affects real websites? If not, we WON'T be taking this change in for next M63 respin (if any).

None of the reports we've had has mentioned a real website. (If such an example exist, now would be a good time to mention it.)

Hi,
I've reported the issue https://bugs.chromium.org/p/chromium/issues/detail?id=792848 which has been merged into this issue.

I'm one of the developer of www.combeenation.com, we provide a system with which our customers (mostly companies) are able to create configurators for their customizable products. Those configurators have sometimes 2D graphics, which we generate via SVG based on their input values.

And since some of our customers are based in germany/austria, they use a lot of umlauts, therefore we had a lot of troubles when the new Chrome 63 rolled out.

Our frontend dev deployed a hotfix where basically all umlauts are replaced via RegEx, but we don't really see this as a long term solution.

An example of a configurator which is using umlauts in SVG (Hotfix is enabled, therefore the graphic is working): https://portal.combeenation.com/Cfgr/pieno/DOORS

So yes we are a real website.

Tested the issue on Windows-7, Ubuntu 14.04 and Mac OS 10.12.6 using chrome latest Canary M65-65.0.3293.0 & 65.0.3287.0(Chrome OS)  by following steps mentioned in the original comment. Observed that images are displaying as expected. Hence adding TE-Verified label.

Please find the snap shot for reference.

Note: For Linux tested in 65.0.3292.0 due to 65.0.3293.0 build failure.

Thank you!

Deleted: 779420.png 494 KB

	779420.png 494 KB View Download

The decision has been made to not merge this into M-63 given the point we're at in the release cycle, the riskiness of the change, and the existence of a (admittedly not great) workaround. Look for it in Chrome 64.

Rejecting merge to M63 based on comment #20.

 Issue 806177  has been merged into this issue.