Bug 211511 – [GTK] Rework clipboard handling in preparation for GTK4

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Carlos Garcia Campos]

Use async APIs to avoid blocking the UI process during the communication with the clipboard. In GTK4 only async APIs are available.

[Carlos Garcia Campos]

Created attachment 398610 [details]
Patch

[Carlos Garcia Campos]

Created attachment 398723 [details]
Patch

[Carlos Garcia Campos]

Created attachment 399013 [details]
Patch

[Adrian Perez]

Comment on attachment 399013 [details]
Patch

Looks good overall, with a few nits you may want to take a look at before landing.


View in context: https://bugs.webkit.org/attachment.cgi?id=399013&action=review

> Source/WebCore/editing/gtk/WebContentReaderGtk.cpp:53
> +bool WebContentReader::readFilePaths(const Vector<String>& paths)

This is exactly the same implementation as for Cocoa, and it seems like a reasonable
default implementation for any port. I would move this into “WebContentReader.cpp” and
share the code.

> Source/WebCore/editing/gtk/WebContentReaderGtk.cpp:93
> +bool WebContentReader::readURL(const URL&, const String&)

The Cocoa port creates an anchor element when reading an URL, resulting in a
fragment with something like “<a href="url">title-or-url</a>” being added.

I think it makes sense to mimic that behavior. Feel free to leave a TODO note
here to do that later on as a follow-up patch.

> Source/WebCore/editing/gtk/WebContentReaderGtk.cpp:98
> +bool WebContentMarkupReader::readHTML(const String&)

This could also be implemented, seems easy enough to call “sanitizeMarkup()” on the
input string and use the result from that.

Feel free to leave it as a TODO for a follow-up patch as well.

> Source/WebCore/platform/gtk/PasteboardGtk.cpp:106
> +    ASSERT(m_selectionData);

Shouldn't this be also a “RELEASE_ASSERT()” as above? It looks like to me
that both assertions should be of the same kind.

[Carlos Garcia Campos]

Comment on attachment 399013 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=399013&action=review

>> Source/WebCore/editing/gtk/WebContentReaderGtk.cpp:93
>> +bool WebContentReader::readURL(const URL&, const String&)
> 
> The Cocoa port creates an anchor element when reading an URL, resulting in a
> fragment with something like “<a href="url">title-or-url</a>” being added.
> 
> I think it makes sense to mimic that behavior. Feel free to leave a TODO note
> here to do that later on as a follow-up patch.

We don't really support URLs, we use _NETSCAPE_URL for drag an drop and the html markup is already generated so it's always handled as text/html. This is never called for GTK port.

>> Source/WebCore/editing/gtk/WebContentReaderGtk.cpp:98
>> +bool WebContentMarkupReader::readHTML(const String&)
> 
> This could also be implemented, seems easy enough to call “sanitizeMarkup()” on the
> input string and use the result from that.
> 
> Feel free to leave it as a TODO for a follow-up patch as well.

I'm not sure this is called for the GTK port either, I'll check.

>> Source/WebCore/platform/gtk/PasteboardGtk.cpp:106
>> +    ASSERT(m_selectionData);
> 
> Shouldn't this be also a “RELEASE_ASSERT()” as above? It looks like to me
> that both assertions should be of the same kind.

No, the other should be ASSERT instead, since I don't usually build with debug I use release assert during development and then convert them to asserts, but I guess I forgot one.

> Source/WebCore/platform/gtk/PasteboardGtk.cpp:249
> +void Pasteboard::read(PasteboardWebContentReader& reader, WebContentReadingPolicy policy, Optional<size_t>)

This is where the WebContentReader is used and we don't call reader.readURL(), that's why it's unimplemented.

[Carlos Garcia Campos]

Created attachment 399126 [details]
Patch for landing

[Carlos Garcia Campos]

Committed r261554: <https://trac.webkit.org/changeset/261554>