Two tests added by http://trac.webkit.org/changeset/146644 fails on Mac port:
@@ -1,5 +1,5 @@
+CONSOLE MESSAGE: line 13: TypeError: 'null' is not an object (evaluating 'event.clipboardData.types.indexOf')
+CONSOLE MESSAGE: line 22: TypeError: 'null' is not an object (evaluating 'event.clipboardData.types.indexOf')
Simple test that data set during a copy/cut event can be read back. To run the test manually, simply select any text and initiate a copy/cut operation.
@@ -1,5 +1,5 @@
+CONSOLE MESSAGE: line 13: TypeError: 'null' is not an object (evaluating 'event.dataTransfer.types.indexOf')
Simple test that data set during a dragstart event can be read back. To run the test manually, simply start dragging the 'Drag Me' element below.
Committed r146652: <http://trac.webkit.org/changeset/146652>
This is a problem specific to the Mac port.
In the new tests, we verify that the data object is both readable and writable in the dragstart/copy/cut events, which the spec and Firefox both allow.
However, the Mac implementation of the Clipboard getters contains the following check:
if (m_changeCount != platformStrategies()->pasteboardStrategy()->changeCount(m_pasteboardName))
Unfortunately, by definition, the change count will be always be different, since we're mutating the clipboard in the first part of the test.
One possibility is to relax this check by skipping the change count check if the clipboard is in a writable state as well, but that seems like a hack. Another possibility would be to update the change count every time an item is written to the clipboard.
The test editing/pasteboard/can-read-in-copy-and-cut-events.html now passes on wk2.
Retitled the bug to reflect the single test failure. Test expectations updated in http://trac.webkit.org/changeset/153465.
This test still fails on wk1 though, so updated results again in <http://trac.webkit.org/r153496>. Re-titling the bug, too.
I'm not actually sure if wk2 success is true, or a consequence of some other bug.
> Another possibility would be to update the change count every time an item is written to the clipboard.
That seems like the way to go to me.
Created attachment 209672 [details]
Unsure why WK2 EWS is still unhappy (can-read-in-copy-and-cut-events.html often fails on EWS, but not on regular WK2 bots).
I have another patch for pasteboard in WTR, hopefully together they will make EWS happier.
Actually, a crash on EWS is real, will post a patch with a null check in a moment.
Created attachment 209676 [details]
editing/pasteboard/dataTransfer-setData-getData.html was crashing because URL it was trying to set was invalid. This used to fail silently with a nil receiver in -writeToPasteboard:.
Not sure what the best behavior in this case is; updated patch proceeds with setting an empty URL in all flavors.
Updated test results in <http://trac.webkit.org/r154653>.