Open saschanaz opened 4 years ago
Thank you for bringing this up at TPAC and following up, and sorry for the delayed reply.
A mixed situation could be useful, but mixing would significantly increase the complexity on the API side (and user agent implementation), where each representation or Blob
in a ClipboardItem
would have to be specified as raw: "true"
or not.
This is especially true when mixing browser-specified and raw formats (ex. In X11, sanitized 'text/plain'
corresponds to 'TEXT'
, 'STRING'
, 'text/plain'
, and 'UTF_STRING'
, so if a web app mixed raw 'TEXT'
in this write with sanitized 'text/plain'
, then this raw 'TEXT'
would override 'TEXT'
but not 'STRING'
, 'text/plain'
, and 'UTF_STRING'
, which may be unexpected to web application authors).
This would also require partial redesign of ClipboardItem
, as items are currently either a dictionary of format to Blob
s (or DOMString
s), and neither of these formats has optional Clipboard-specific parameters. This could take the form of something like a ClipboardItemDataWithOptions
object.
I think this API was mostly designed for use through:
That said, the W3C Clipboard API + Raw Clipboard Access proposal doesn't preclude mixing of raw and sanitized clipboard data, in the event that multiple ClipboardItems
are implemented. This could be accomplished by having one ClipboardItem
be raw: true
, and another be raw: false
.
So sorry, I don't think there's a planned way to allow raw: "mixed"
within the scope of one ClipboardItem
, and this does unfortunately mean that in the use case you mentioned, web application code would have to change more if the mentioned image format were to be worked around and later supported directly in a browser.
From TPAC 2019.
So it seems
raw: true
always turns off the sanitizer, but could a mixed situation be helpful, where the supported formats are still sanitized and only the unsupported ones gets the raw access?Consider we have a bleeding edge great new image format and a web app wants to write that format into the clipboard. Because browsers do not support that format, the app will have to pass
raw: true
to workaround the problem. And then, because the new image format is super great, the browsers might add the support later.A way to do mixed check, maybe
raw: "mixed"
or similar, might allow the same code to support the new format could become automatically more secure by future potential browser update adding the format support.What do you think?