Bug 225340 – When assigning to the src value for a constructed Image(), Safari 14.1 mangles the string

• Status: RESOLVED
• Resolution: WONTFIX
• Component: JavaScriptCore

[Jarod Gowgiel]

When assigning an SVG string that is not URI encoded to the src value of a constructed Image (https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/Image) the resulting string is mangled by Safari 14.1 but not Safari 14.0.3.

I'm not sure specifically where this bug lies (JavaScriptCore or WebCore JavaScript) but I believe it must be in the JavaScript engine somewhere.

As demonstrated in https://codepen.io/JarodG/pen/KKaOjRG?editors=1011 - notice:

In both Safari 14.0.3 and Chrome 89.0.4389.128, assigning a simple SVG string to the src attribute maintains the same structure and formatting when read as the initial string. In Safari 14.1, however, assigning an SVG string to the same attribute causes the string to seemingly become partially encoded after an indeterminate point.

The string in question goes from: 

'<svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 36 36"> <path fill="#DD2E44" d="M35.885 11.833c0-5.45-4.418-9.868-9.867-9.868-3.308 0-6.227 1.633-8.018 4.129-1.791-2.496-4.71-4.129-8.017-4.129-5.45 0-9.868 4.417-9.868 9.868 0 .772.098 1.52.266 2.241C1.751 22.587 11.216 31.568 18 34.034c6.783-2.466 16.249-11.447 17.617-19.959.17-.721.268-1.469.268-2.242z"/></svg>'

to

'<svg xmlns='http://www.w3.org/2000/svg' width='20' height='20' viewBox='0 0 36 36'> <path fill='#DD2E44%22%20d=%22M35.885%2011.833c0-5.45-4.418-9.868-9.867-9.868-3.308%200-6.227%201.633-8.018%204.129-1.791-2.496-4.71-4.129-8.017-4.129-5.45%200-9.868%204.417-9.868%209.868%200%20.772.098%201.52.266%202.241C1.751%2022.587%2011.216%2031.568%2018%2034.034c6.783-2.466%2016.249-11.447%2017.617-19.959.17-.721.268-1.469.268-2.242z%22/%3E%3C/svg%3E'

I'm aware that setting the data URI like this is not the best practice, but wanted to report this as a deviation from the previous version of Safari (and a change which I couldn't find recorded anywhere).

[Radar WebKit Bug Importer]

<rdar://problem/77521469>

[Alex Christensen]

This changed with https://trac.webkit.org/changeset/266399/webkit which adopts the behavior of the URL specification at https://url.spec.whatwg.org/#fragment-state
The percent encoding starts after the '#' character, which begins the fragment of the URL.  Your example also percent encodes those spaces in Firefox.

I've noticed some odd things about fragment encoding in different browsers:
Browser     | new URL("data://example.com/# <>") | new URL("data://example.com/# <>")
-------------------------------------------------------------------------------------
Firefox 88  | data://example.com/#%20<>          | http://example.com/#%20%3C%3E
Chrome 90   | data://example.com/# <>            | http://example.com/#%20%3C%3E
Safari 14.1 | data://example.com/#%20%3C%3E      | http://example.com/#%20%3C%3E

I've raised https://github.com/whatwg/url/issues/597 and intend to implement my proposed change to increase compatibility, which would revert https://trac.webkit.org/changeset/266399/webkit for non-special schemes.

[Alex Christensen]

Created attachment 427711 [details]
Patch

[EWS Watchlist]

This patch modifies the imported WPT tests. Please ensure that any changes on the tests (not coming from a WPT import) are exported to WPT. Please see https://trac.webkit.org/wiki/WPTExportProcess

[Alex Christensen]

Comment on attachment 427711 [details]
Patch

Since we follow the specification which seems to not want to change, and because Firefox behaves the same way in this case, I'm going to say we won't fix this for now.