Re: [w3c/editing] Should we modify the clipboard API spec to match Safari's behavior for HTML-referenced media? (#285)

Sorry I've been a bit slow to respond. 

> new proposal

The new proposal generally seems fine to me, though I admittedly haven't spent too much time thinking about this due to some other work. I think it may be a bit odd to add an `includeFiles` arg to apply only for the "text/html" format, but I don't have any better plan now, and the described name/behavior makes sense. I assume `includeFiles` wouldn't apply to any other clipboard format, and that blob lifetime starts after calling `getType` with `includeFiles`. I'm not sure I understand when the blobs would become revoked though... (when they leave their JS scope?)

No objection from me, assuming blob lifetime is ok (deferring there to @mkruisselbrink ).

> how do we know that the file referenced in the html markup is from a native application.

I believe (but am unsure) that file references are always stripped when Chrome writes to the clipboard (per [tests](https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/svg/unsafe_svg_attribute_sanitization_test.cc)). Therefore, any file objects read in the Chrome clipboard should be from the OS clipboard (other native applications).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/285#issuecomment-818335142