[Webkit-unassigned] [Bug 211979] [GTK] Enable the async clipboard API

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue May 19 06:40:40 PDT 2020


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

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darin at apple.com,
                   |                            |rniwa at webkit.org,
                   |                            |wenson_hsieh at apple.com

--- Comment #1 from Carlos Garcia Campos <cgarcia at igalia.com> ---
I've started to work on this, but there are two things that I don't think we will be able to support:

1. Writing multiple items in the clipboard. I don't think that's supported in Linux, at least it's not possible using the GTK APIs. This shouldn't be a blocker, thouch, chromium doesn't support it either, we an just raise a NotAllowedError when write is called with mor than 1 item like chromium does.

2. Detecting clipboard changes to reject data access from items. I think this is actually an optimization of the WebKit implementation. When reading the clipboard contents only the item information is read, not the actual data. And when the item data is accessed then the data is actually read. The problem of this approach is that between clipboard.read() and item.getType() the contents of the system clipboard might change. In Mac there's a changeCount in the NSPasteboard, so that it can be detected to make item.getType() raise an exception. I'm not sure this is the expected behavior according to the spec, though, as I understand it it should return the previous data, because it's expected to be retrieved on clipboard.read(). We don't have a way to detect changes in the clipboard (unless we are the current owner), so this approach doesn't work for us. I guess we can't just return always the current clipboard contents and assume this is an edge case that hardly ever happens. So, the only solution would be for us to read also the data on clipboard.read(). This can be very inefficient if there's an image in the clipboard when we are going to read it as html, for example.

-- 
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/20200519/31aee533/attachment.htm>


More information about the webkit-unassigned mailing list