I have a patch for this in the works.
Created attachment 202011 [details] Patch
This patch is a bit silly because EFL does not implement clipboard operations at all. Because there is no EWS bot for EFL, I need help from someone who works on the EFL port to test this patch.
Comment on attachment 202011 [details] Patch Attachment 202011 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/486271
Comment on attachment 202011 [details] Patch Attachment 202011 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/493138
Created attachment 202043 [details] Patch
Created attachment 202044 [details] Patch
Comment on attachment 202044 [details] Patch Attachment 202044 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/487268
Comment on attachment 202044 [details] Patch Attachment 202044 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/489183
Created attachment 202045 [details] Patch
Comment on attachment 202045 [details] Patch Attachment 202045 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/481773
Comment on attachment 202045 [details] Patch Attachment 202045 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/491198
Comment on attachment 202045 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=202045&action=review > Source/WebCore/ChangeLog:13 > + * page/efl/EventHandlerEfl.cpp: Removed EventHandler::createDraggingClipboard > + function since DRAG_SUPPORT is not defined for EFL anyway. DRAG_SUPPORT is on for EFL by default. See wtf/FeatureDefines.h, OptionsEFL.cmake or the EWS build logs > Source/WebCore/ChangeLog:20 > + Deleted unneeded writePlainText, writeSelection, and writeURL functions. The EWS bots seem to disagree that they are unneeded.
(In reply to comment #12) > > Source/WebCore/ChangeLog:13 > > + * page/efl/EventHandlerEfl.cpp: Removed EventHandler::createDraggingClipboard > > + function since DRAG_SUPPORT is not defined for EFL anyway. > > DRAG_SUPPORT is on for EFL by default. See wtf/FeatureDefines.h, OptionsEFL.cmake or the EWS build logs That seems silly. None of the underlying code for dragging seems to be there. It’s all just notImplemented(). Maybe there is some way to use dragging within a webpage without any of the platform dragging hooked up? > > Source/WebCore/ChangeLog:20 > > + Deleted unneeded writePlainText, writeSelection, and writeURL functions. > > The EWS bots seem to disagree that they are unneeded. Yes, they would be unneeded if DRAG_SUPPORT wasn’t on. OK. I’ll do the version of this patch with lots more notImplemented(). As I said, very silly.
Created attachment 202092 [details] Patch
(In reply to comment #13) > (In reply to comment #12) > > > Source/WebCore/ChangeLog:13 > > > + * page/efl/EventHandlerEfl.cpp: Removed EventHandler::createDraggingClipboard > > > + function since DRAG_SUPPORT is not defined for EFL anyway. > > > > DRAG_SUPPORT is on for EFL by default. See wtf/FeatureDefines.h, OptionsEFL.cmake or the EWS build logs > > That seems silly. None of the underlying code for dragging seems to be there. It’s all just notImplemented(). If it makes more sense, removing the line which enables it in OptionsEFL.cmake should be easy, and if that's OK with you #ifdef'ing the part which enables it in FeatureDefines.h is also fine. This should also decrease the amount of silliness in this patch :-)
(In reply to comment #15) > If it makes more sense, removing the line which enables it in OptionsEFL.cmake should be easy, and if that's OK with you #ifdef'ing the part which enables it in FeatureDefines.h is also fine. This should also decrease the amount of silliness in this patch :-) I think my new try will probably be OK. But someone who works on EFL should figure out why the feature is on. There’s no point turning it on if the back end is not implemented.
(In reply to comment #16) > But someone who works on EFL should figure out why the feature is on. Before the CMake changes got in and FeatureDefines.h was created, it looks like it was on by default on !iOS in Platform.h (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/Platform.h?rev=114985), so I guess people just implemented stubs to get the code compiling when the port was upstreamed.
Comment on attachment 202092 [details] Patch Attachment 202092 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/482822
Comment on attachment 202092 [details] Patch Attachment 202092 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/497015
Created attachment 202097 [details] Patch
Comment on attachment 202097 [details] Patch Attachment 202097 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/492369
Comment on attachment 202097 [details] Patch Attachment 202097 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/493323
Created attachment 202098 [details] Patch
Comment on attachment 202098 [details] Patch Attachment 202098 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/493328
Created attachment 202099 [details] Patch
Comment on attachment 202099 [details] Patch Attachment 202099 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/486466
Comment on attachment 202099 [details] Patch Attachment 202099 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/481944
Created attachment 202101 [details] Patch
Comment on attachment 202101 [details] Patch Attachment 202101 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/497028
Comment on attachment 202101 [details] Patch Attachment 202101 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/492382
Created attachment 202103 [details] Patch
Committed r150268: <http://trac.webkit.org/changeset/150268>