Enable the async clipboard API
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.
*** Bug 212742 has been marked as a duplicate of this bug. ***
*** Bug 253749 has been marked as a duplicate of this bug. ***
*** Bug 253793 has been marked as a duplicate of this bug. ***
Pull request: https://github.com/WebKit/WebKit/pull/11550
Committed 261740@main (ec3dd91419a8): <https://commits.webkit.org/261740@main> Reviewed commits have been landed. Closing PR #11550 and removing active labels.