Bug 211979 - [GTK] Enable the async clipboard API
Summary: [GTK] Enable the async clipboard API
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Carlos Garcia Campos
: 212742 253749 253793 (view as bug list)
Depends on: 177633
Blocks: 206653 212232 253758
  Show dependency treegraph
Reported: 2020-05-16 02:52 PDT by Carlos Garcia Campos
Modified: 2023-03-24 05:31 PDT (History)
11 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 2020-05-16 02:52:30 PDT
Enable the async clipboard API
Comment 1 Carlos Garcia Campos 2020-05-19 06:40:40 PDT
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.
Comment 2 Diego Pino 2020-06-04 06:13:54 PDT
*** Bug 212742 has been marked as a duplicate of this bug. ***
Comment 3 Michael Catanzaro 2023-03-11 10:35:56 PST
*** Bug 253749 has been marked as a duplicate of this bug. ***
Comment 4 Michael Catanzaro 2023-03-12 08:44:52 PDT
*** Bug 253793 has been marked as a duplicate of this bug. ***
Comment 5 Carlos Garcia Campos 2023-03-15 07:23:12 PDT
Pull request: https://github.com/WebKit/WebKit/pull/11550
Comment 6 EWS 2023-03-16 04:42:35 PDT
Committed 261740@main (ec3dd91419a8): <https://commits.webkit.org/261740@main>

Reviewed commits have been landed. Closing PR #11550 and removing active labels.