[Webkit-unassigned] [Bug 214578] New: user selection via paste/drop loses characters translating to RTF/RTFD & attributed string output across iframe

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=214578

            Bug ID: 214578
           Summary: user selection via paste/drop loses characters
                    translating to RTF/RTFD & attributed string output
                    across iframe
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: iPhone / iPad
                OS: iOS 13
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: danhite at me.com

Hello hard working webkit devs!

webkit serializes user selected html to many UTI forms upon a copy or drop and this simple test case shows two kinds of character loss...

data:text/html,<pre>RTF%20U%20<iframe%20srcdoc="pity%20the%20<b>fool"></iframe>%0AMIA%20space%20and%20last%20letter

is a complete miniature webpage to replicate the bug, as I have, on both ipadOS 13.6 safari 13 and on 14beta2 (iirc 14 ~preview 109)

in case ^ that url is hard for you to read, here's the two lines of .html source ...

<pre>RTF U <iframe srcdoc="pity the <b>fool"></iframe>
MIA space and last letter

simply select all the page (ie from RTF through letter) and either "copy" or
drag it to files app or a shelf app like gladys, for convenience of examining the UTI thunks that webkit output

the files app makes an .rtfd that is buggy (webkit's fault), as you can easily see by using quicklook
and within the copy pasteboard (eg looking via gladys) both the rtfd , rtf, and attributed string forms all have the bug, ie ...

RTF Upity the foo
MIA space and last letter

instead of ...

RTF U pity the fool
MIA space and last letter

so both the space character outside preceding the iframe, and the last character within the iframe, got omitted from the serialization

naturally the webpage itself is displaying properly; also just selecting within the iframe seems fine, it's crossing it that messes up

it's a very cool feature that you empower user's to drag/copy across iframe content, so I listed this as "normal" severity since user's are losing data in a non-obvious way--for example, if the last characters in the iframe were $100 now the saved data concludes with $10, and they might not notice the bug, oops, or perhaps I've attempted to say: "I want to bathe in your pool" and somehow the result doesn't quite feel the same ;)

note that the safari serialization to html, com.apple.webarchive, or, if chosen via share menu, pdf output, all work properly

apparently this is a common edge case where the serializer code chokes up splicing in the contents of an iframe within a user selection

regards,
Dan

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200720/688c2e42/attachment.htm>