short summary, user text data is lost by mangling, eg IsCapitalized:IAmCapitalized via paste into Safari buggily becomes iscapitalized:IAmCapitalized ... if my details below are tl;dnr then try this ... find yourself any webpage with a <textarea> or <input> field type into that field just these three characters : J:J select them, cut them, paste them back into the field, and observe buggy as now : j:J ... tested using Safari 14.01 on an iPhone or Safari 14.2beta3 on an iPad ... (ie I did not dig up Safari 13 et al, sorry) This is problem with dropping also, but not as bad, so let's start with * pasting * into Safari ... First off, pasting into the URL bar is fine, so that can be an easy sanity check for you. Pasting into <textarea> or <input> field or ContentEditable (even if such is plaintext-only) will alter the user's text unnecessarily under the following conditions ... if the text, roughly speaking, passes an internal test for text === escape( text ) then some overzealous code thinks it's a url scheme if there's a colon in it and thus decides to needlessly lowercase the portion before the colon. That is, this bug will not manifest if there's eg a space or other character within the pasteboard text that would need to escape(textAsURL) [ let me just mention here, as an aside, that the Apple code used in your apps, eg Notes, to determine whether some text as a whole is in fact a URL, is outdated, ie akin to escape not encodeURIComponent et al , and this results sometimes in a bad user experience, as eg Notes makes said text into a clickable ~URL , but mangles the url/appearance ] eg (and note I'm triggering the bug at this very moment, by pasting below my example, and thus had to edit the following to fix it!) BothCamelCase:BothCamelCase ^ as text in the clipboard (tested as the sole pasteboard item type, for clarity and unambiguity) pasted into Safari comes out erroneously as bothcamelcase:BothCamelCase unless, as mentioned, pasted to the url bar, which demonstrates there's no reason to prematurely vet the text even if it begins with a url scheme, especially since it's nice to have case preservation for non urls go to search engine query text as-is ... the drag/drop case is less buggy, as dropping in just a text type dataTransfer works sans lowercasing-before-colon, but if there is a public.url , even if it isn't the first type in the dto and even though the receiver is text-only, then it * is * mangled (testing caveat: safari default action dropping text into ContentEditable is fine, but eg into a textarea will bubble up to a url bar navigation unless preventDefault ... this is a mis/feature depending upon your POV ; here it effectively further limits the impact of this bug wrt user drop) ... I left this bug as "normal" severity because I, as an author/user of textarea using web pages, have been bitten in the butt at least once by my copy paste not being equal to the prior field value. Clearly it's "minor" in the sense that a small% of people will trigger it, and once you do you can be ready to repair the damage
Thanks for filing, I can reproduce this on iOS 13.5.1 as well as 14.0 using https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textarea.
<rdar://problem/70584666>
This is still a problem with iOS 16.3