Use async APIs to avoid blocking the UI process during the communication with the clipboard. In GTK4 only async APIs are available.
Created attachment 398610 [details] Patch
Created attachment 398723 [details] Patch
Created attachment 399013 [details] Patch
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.
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.
Created attachment 399126 [details] Patch for landing
Committed r261554: <https://trac.webkit.org/changeset/261554>