The tests below fail on WebKitGTK+ since they were added on r222595 <https://trac.webkit.org/r222595> 1) editing/pasteboard/data-transfer-get-data-on-paste-rich-text.html [ Failure ] 2) editing/pasteboard/data-transfer-get-data-on-paste-plain-text.html [ Failure ] 3) editing/pasteboard/data-transfer-get-data-on-paste-custom.html [ Failure ] The text failures: 1) https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20(Tests)/r222597%20(3376)/editing/pasteboard/data-transfer-get-data-on-paste-rich-text-pretty-diff.html 2) https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20(Tests)/r222597%20(3376)/editing/pasteboard/data-transfer-get-data-on-paste-plain-text-pretty-diff.html 3) https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20(Tests)/r222597%20(3376)/editing/pasteboard/data-transfer-get-data-on-paste-custom-pretty-diff.html
(In reply to Carlos Alberto Lopez Perez from comment #0) > The tests below fail on WebKitGTK+ since they were added on r222595 > <https://trac.webkit.org/r222595> > > 1) editing/pasteboard/data-transfer-get-data-on-paste-rich-text.html [ > Failure ] > 2) editing/pasteboard/data-transfer-get-data-on-paste-plain-text.html [ > Failure ] > 3) editing/pasteboard/data-transfer-get-data-on-paste-custom.html [ Failure ] > > The text failures: > > 1) > https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20(Tests)/ > r222597%20(3376)/editing/pasteboard/data-transfer-get-data-on-paste-rich- > text-pretty-diff.html > 2) > https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20(Tests)/ > r222597%20(3376)/editing/pasteboard/data-transfer-get-data-on-paste-plain- > text-pretty-diff.html > 3) > https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20(Tests)/ > r222597%20(3376)/editing/pasteboard/data-transfer-get-data-on-paste-custom- > pretty-diff.html Oh -- the new custom pasteboard data codepaths have only been implemented on Cocoa platforms (iOS, macOS) so far, so this is expected. Is the standard procedure to mark these tests as [ Skip ] or [ Failure ] in GTK platform TestExpectations?
(In reply to Wenson Hsieh from comment #1) > Is the standard procedure to mark these tests as [ Skip ] or [ Failure ] in GTK platform TestExpectations? Yes. I'm doing that in bug 177635
It would be really good for GTK+ to move to new Pasteboard API so that copy/paste drag/drop code would be more maintainable in the long run. I'm hoping to take about at the contributor's meeting as well.
According to Ryosuke, we have to implement: * Pasteboard::typesSafeForBindings() * Pasteboard::writeCustomData(const PasteboardCustomData&) * Pasteboard::readOrigin() * Pasteboard::readStringForCustomData(const String&)
Reading the commit message of r222595 it seems to me the problem is specific to Mac. I don't think we are exposing any private data types of other apps to the web.
hmm, I'm now reading https://www.w3.org/TR/clipboard-apis/ is that spec what the new API implements?
(In reply to Carlos Garcia Campos from comment #5) > Reading the commit message of r222595 it seems to me the problem is specific > to Mac. I don't think we are exposing any private data types of other apps > to the web. For the most part, that's right: Mac has tons of weird data in the clipboard that should not be web-exposed, which doesn't happen on Linux. But we probably want to filter out text/uri-list. E.g. if you drag file:///home/mcatanzaro/cats.png into imgur, you want it to see the bytes of the file as image data, you don't want it to actually see file:///home/mcatanzaro/cats.png and learn your private disk layout.
(In reply to Carlos Garcia Campos from comment #6) > hmm, I'm now reading https://www.w3.org/TR/clipboard-apis/ is that spec what > the new API implements? The custom pasteboard data codepath primarily ensures that the page is able to supply arbitrary data types using the clipboard APIs (e.g., dataTransfer.setData('myCustomType', 'myCustomData')) without directly affecting the contents of the real platform pasteboard. To do this, we package all the custom pasteboard types and data supplied by web content (as well as some metadata, such as the document origin) into a separate blob of data that we refer to as "custom pasteboard data". On Cocoa platforms, this is written as a separate UTI on the platform pasteboard: "com.apple.WebKit.custom-pasteboard-data". Additionally, by including the origin of the page in the custom pasteboard data, we're able to enforce stricter checks on what data we expose cross-origin through clipboard APIs. For instance, r223195 uses the custom pasteboard data mechanism to sanitize URLs cross-origin, but maintain original data when dropping/pasting in a page of the same origin.
*** Bug 178454 has been marked as a duplicate of this bug. ***
editing/pasteboard/copy-paste-across-shadow-boundaries-with-style-2.html is crashing since added in r236785
There are 2 tests that were passing that are flaky now: editing/pasteboard/paste-text-with-style.html [ Failure Pass ] with diff: --- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/editing/pasteboard/paste-text-with-style-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/editing/pasteboard/paste-text-with-style-actual.txt @@ -4,7 +4,7 @@ EDITING DELEGATE: shouldChangeSelectedDOMRange:range from 0 of DIV > BODY > HTML > #document to 0 of DIV > BODY > HTML > #document toDOMRange:range from 0 of #text > I > B > DIV > BODY > HTML > #document to 9 of #text > FONT > DIV > DIV > BODY > HTML > #document affinity:NSSelectionAffinityDownstream stillSelecting:FALSE EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification EDITING DELEGATE: shouldInsertNode:#document-fragment replacingDOMRange:range from 0 of #text > I > B > DIV > BODY > HTML > #document to 9 of #text > FONT > DIV > DIV > BODY > HTML > #document givenAction:WebViewInsertActionPasted -EDITING DELEGATE: shouldChangeSelectedDOMRange:range from 0 of DIV > BODY > HTML > #document to 0 of DIV > BODY > HTML > #document toDOMRange:range from 9 of #text > FONT > DIV > DIV > BODY > HTML > #document to 9 of #text > FONT > DIV > DIV > BODY > HTML > #document affinity:NSSelectionAffinityDownstream stillSelecting:FALSE +EDITING DELEGATE: shouldChangeSelectedDOMRange:range from 0 of DIV > BODY > HTML > #document to 0 of DIV > BODY > HTML > #document toDOMRange:range from 11 of #text > DIV > BODY > HTML > #document to 11 of #text > DIV > BODY > HTML > #document affinity:NSSelectionAffinityDownstream stillSelecting:FALSE EDITING DELEGATE: webViewDidChangeSelection:WebViewDidChangeSelectionNotification EDITING DELEGATE: webViewDidChange:WebViewDidChangeNotification EDITING DELEGATE: webViewDidEndEditing:WebViewDidEndEditingNotification @@ -26,15 +26,7 @@ " Markup after: -| <b> -| <i> -| "hello bold and italic" -| <div> -| <i> -| "hello italic" -| <div> -| <font> -| color="#ff0000" -| "hello red<#selection-caret>" +| "hello world<#selection-caret>" +| <br> | " " editing/pasteboard/paste-without-nesting.html [ Failure Pass ] with diff --- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/editing/pasteboard/paste-without-nesting-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/editing/pasteboard/paste-without-nesting-actual.txt @@ -1,7 +1,7 @@ This test checks that copy a selection and paste over the same selection does not create nested divs. PASS confirmedMarkup is 'Hello' -PASS confirmedMarkup is 'Hello<br>world' +FAIL confirmedMarkup should be Hello<br>world. Was Hello. PASS confirmedMarkup is '<div>Hello</div><div>world</div>' PASS confirmedMarkup is '<div>Hello</div><div>world</div>' PASS confirmedMarkup is '<div><b><i>Hello</i></b></div><div><b><i>world</i></b></div>'
*** Bug 189737 has been marked as a duplicate of this bug. ***
*** Bug 81320 has been marked as a duplicate of this bug. ***
*** Bug 196541 has been marked as a duplicate of this bug. ***
Created attachment 399547 [details] Patch
Committed r261792: <https://trac.webkit.org/changeset/261792>