Contact emails [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]>
Specification https://w3c.github.io/clipboard-apis/#optional-data-types-x Design docs None. See summary. Summary On Windows, popular native apps [1] use UTF-8 format to read/write SVG images from/to clipboard. Proposal is to switch to UTF-8 on Windows while writing `image/svg+xml` format to the clipboard. This is similar to the HTML format where we use UTF-8 on Windows. When SVG image content is read from the clipboard, Chromium converts it into UTF-16. In M124, support for `image/svg+xml` native format was shipped in async clipboard APIs. In Chromium, SVG image is written to the clipboard in UTF-16 format on Windows. Many popular apps [1] on Windows use UTF-8 encoding to read/write SVG images from/to clipboard. Hence, when a user tries to copy SVG images from Chromium and paste into one of these native apps, the image will be parsed incorrectly and will not render after paste. This can be reproduced by visiting https://webdbg.com/test/svg/ or https://heathered-spotty-fin.glitch.me/ to copy `image/svg+xml` to the clipboard and paste it into native Word. The paste succeeds but the image doesn't render because of the invalid encoding. Proposal is to switch to UTF-8 on Windows while writing `image/svg+xml` format to the clipboard. This is similar to the HTML format where we use UTF-8 on Windows too. [2] Alternative considered It was attempted to add a BOM character to the UTF-16LE encoded SVG image content, but the sampled native apps [1] were unable to parse the images correctly. [1] Here is an inventory of all the sampled native apps that read/write `image/svg+xml` format: https://docs.google.com/document/d/1ULlihA0FOJOqcyD9MgzLZrAbk0uTQPJqDPuPJ2aiuS4/edit?usp=sharing [2] https://learn.microsoft.com/en-us/windows/win32/dataxchg/html-clipboard-format#:~:text=The%20only%20character%20set%20supported%20by%20the%20clipboard%20is%20Unicode%20(UTF%2D8)<https://learn.microsoft.com/en-us/windows/win32/dataxchg/html-clipboard-format#:~:text=The%20only%20character%20set%20supported%20by%20the%20clipboard%20is%20Unicode%20(UTF-8)>. Blink component Blink>DataTransfer<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDataTransfer> Search tags image/svg+xml<https://chromestatus.com/features#tags:image/svg+xml>, AsyncClipboard API<https://chromestatus.com/features#tags:AsyncClipboard%20API> TAG review None TAG review status Not applicable because it doesn’t change the API surface. Risks Interoperability and Compatibility If a native app expects the SVG image content to be in UTF-16 format in the clipboard, then there is risk that paste might break in those apps after this change. However, after testing against 30 popular native Windows apps<https://www.microsoft.com/en-us/store/most-popular/apps/pc> that are relevant to document editing, we’ve found no apps that relied on UTF-16. All used UTF-8 encoding scheme to read/write SVG images from/to clipboard. Therefore we evaluate that there is minimal compatibility risk associated with this change. Currently, the SVG content is converted from UTF-8 to UTF-16 in Chromium before writing to the clipboard. With this proposal, we are just removing this conversion, so there is no negative impact to performance. Gecko: No Signal. SVG format support is not implemented by Firefox, but they have plans to implement it in the future<https://github.com/mozilla/standards-positions/issues/549>. WebKit: No Signal. SVG format support is not implemented by Safari, but they have plans to implement it in the future<https://lists.webkit.org/pipermail/webkit-dev/2021-August/031940.html>. Web developers: Positive (https://issues.chromium.org/issues/338250106) Other signals: Ergonomics Not applicable because it doesn’t change the API surface. Activation Not applicable because it doesn’t change the API surface. Security Not applicable because it doesn’t reveal any new information. WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None as this change only impacts Windows. Debuggability N/A as it is about writing UTF-8 encoded SVG image to the system clipboard. There is already support for debugging async clipboard APIs in DevTools. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? This change is only on Windows to make it consistent with other native apps that read/write UTF-8 encoded SVG images from/to the clipboard. Is this feature fully tested by web-platform-tests<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? No,the behavior change is not testable on WPT tests because it requires an interaction with a native app. Flag name on chrome://flags UseUtf8EncodingForSvgImage Finch feature name UseUtf8EncodingForSvgImage Non-finch justification None Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/338250106 Estimated milestones Shipping on desktop 127 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way). None Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5417299782926336 This intent message was generated by Chrome Platform Status<https://chromestatus.com/>. Thanks, Anupam Sent from Outlook<http://aka.ms/weboutlook> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SJ0PR00MB0991689EFE2EB91B29BDFAE1CFC02%40SJ0PR00MB0991.namprd00.prod.outlook.com.
