Issue metadata
Sign in to add a comment
|
SVG href identifier with umlaut won't be displayed
Reported by
patrick....@gmail.com,
Dec 7 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36 Example URL: https://jsfiddle.net/594ncuns/5/ Steps to reproduce the problem: 1. Open JsFiddle https://jsfiddle.net/594ncuns/5/ What is the expected behavior? The SVG which is referenced in the use element should be displayed. What went wrong? The SVG won't be displayed because apparently the id contains an umlaut. The SVG is visible, if the umlaut will be omitted. Working example without umlaut: https://jsfiddle.net/594ncuns/6/ This bug emerged with the update to Chrome 63. Chrome 62, Firefox 57 and Edge are displaying the SVG correctly. Does it occur on multiple sites: Yes Is it a problem with a plugin? N/A Did this work before? Yes Chrome v62 Does this work in other browsers? Yes Chrome version: 63.0.3239.84 Channel: stable OS Version: 10.0 Flash Version:
,
Dec 7 2017
Able to reproduce the issue and this is a regression which started in M63 please find the bisect result below and marking the bug as stable blocker based on the regression range : Bisect result : You are probably looking for a change made after 507480 (known good), but no later than 507481 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/0a918e900a759b04f177cc5b8bca668140751136..f8f6ed59949be4451ee2f5443d8a313f102fde60 Note : The same works fine on latest Chrome dev(64.0.3278.0) and Canary(65.0.3287.0)
,
Dec 7 2017
This blocking further M63 stable roll out. Please take a look ASAP and let us know if it is not a blocker. Thank you.
,
Dec 7 2017
+candrada@, please try to repro on Android as this is a Blink bug.
,
Dec 7 2017
+eisinger@, could you ptal as mkwst@ is OOO. Thank you.
,
Dec 7 2017
it works on trunk, so I suppose this was fixed in between? could you please also bisect from trunk to see when this was fixed?
,
Dec 7 2017
also not sure why this is a stable blocker?
,
Dec 7 2017
As it was regressed in M63, it was marked as Stable blocker at comment #2. Please feel free to remove blocker label if you think it is not a blocker. Thank you.
,
Dec 7 2017
Did the reverse bisect and below is the CL which fixed the issue : Reverse bisect : You are probably looking for a change made after 512894 (known good), but no later than 512895 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/18afd13d94183587e05cb04031f2ee7d56ba98d9..7fed5aeb041c935425adb69333bdf610bef896ee
,
Dec 7 2017
Bug also affects Android. Broken in M63 and is fixed in M64 and M65.
,
Dec 7 2017
How widespread is this issue? is it affecting all websites? all devices?
,
Dec 7 2017
AFAIK we don't have any report this affects real websites at least for Desktop, correct pbommana@?
,
Dec 7 2017
It's difficult to say how widespread this is - I hadn't even seen non-latin fragment identifiers in the wild prior to issue 779420 . As mentioned in c#12, this hasn't been reported against any real websites. The fix is fairly well-contained and safe (and will have been in 64 for a while by now.)
,
Dec 8 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Dec 7 2017