[Webkit-unassigned] [Bug 199975] WebKit should strip away system font names from the pasted content

[bugzilla-daemon at webkit.org]

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

--- Comment #2 from Ryosuke Niwa <rniwa at webkit.org> ---
Created attachment 374539

  --> https://bugs.webkit.org/attachment.cgi?id=374539&action=review

Paste side fix

We can fix this either during copy or upon paste.

Fixing this in the paste side is simple to understand. We strip away any .Apple / .SF font names we encounter in ReplaceSelectionCommand.

Fixing this in the copy site works even when Cocoa HTML Writer generates HTML because we have copy-paste sanitization code which inserts the original HTML into a dummy document then re-serializes back to HTML before the actual pasting happens. This secondary serialization step uses our copy code.

After going back & forth about the two approaches, I think we should go with the copy side fix. It has a few benefits:

1. It would only affect clients that opts-in to copy & paste sanitization. e.g. it won't affect clients of legacy WebKit API and those who opt out of custom pasteboard data.

2. We can preserve font names such as ".SF Blah" that a website inserts as some kind of house keeping purposes (who knows what kind of a website might be doing this). Copy side fix would only affect cross-site pasting and cross-app pasting, which is rare and less likely to be affected by this kind of house keeping code.

3. We won't expose bogus .Apple* or .SF* font names to websites that directly use event.clipboardData.getData during a paste event. Stripping away bogus markup like this is one of the key features / benefit of using copy & paste sanitization code.

-- 
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/20190720/1532b98e/attachment.html>