58206 2011-04-10 10:46:52 -0700 [Qt] HTML5 drag and drop not working when getData is used 2014-02-03 03:17:30 -0800 1 1 1 Unclassified WebKit WebKit Misc. 528+ (Nightly build) PC Linux RESOLVED INVALID Qt, QtTriaged P2 Normal --- 56486 0 aparna.nand webkit-unassigned benjamin cricri.bug dtrebbien eric ossy rhemalinder robertc oldest_to_newest 382908 0 aparna.nand 2011-04-10 10:46:52 -0700 Steps to reproduce the problem: 1. Open QtTestBrowser or any other simple app that with QWebView 2. Load http://ljouanneau.com/lab/html5/demodragdrop.html. This page has HTML5 drag and drop. 3. Perform the operations in the page as illustrated - that is drag boxes. Expected result: Dragging and dropping of boxes is possible as illustrated in the page Actual result: Unable to drag the content Other information: https://bugs.webkit.org/show_bug.cgi?id=56486 has been raised for a similar issue but the problem with other websites mentioned in 56486 is different from this bug, hence raising another bug for this as discussed. 382910 1 aparna.nand 2011-04-10 10:59:50 -0700 Analysis: It is found that the value returned by getData in the following script in wrong: function dragOver(ev) { var idelt = ev.dataTransfer.getData("Text"); var id = ev.target.getAttribute('id'); if( (id =='boxB' || id =='boxA') && (idelt == 'drag' || idelt=='drag2')) return false; else if( id =='boxC' && idelt == 'drag3') return false; else return true; } idelt is always undefined. On the other hand if the same web page (http://ljouanneau.com/lab/html5/demodragdrop.html) is downloaded and saved as html and opened through the QtTestBrowser, it works fine. Problem in the code: String ClipboardQt::getData(const String& type, bool& success) const { if (policy() != ClipboardReadable) { success = false; return String(); } .... } The policy value is set as ClipboardTypesReadable in this case hence empty string is returned. The policy value is set in DragController::tryDHTMLDrag. If the URL is local, then clipboardReadable is set (which is why it works when the same html page is saved locally and then loaded in QtTestBrowser) else clipboardTypesReadable is set. Additional information: To get this fix working, patch in https://bugs.webkit.org/show_bug.cgi?id=56486 is a required (which is to get generic HTML5 drag and drop to work) 382912 2 88954 aparna.nand 2011-04-10 11:11:34 -0700 Created attachment 88954 Patch for review getData JavaScript API is an important integral part of HTML5 D&D usage which is always returning an undefined value in this case. Fix rectifies this problem. Existing test cases cover D&D. DRT does not support D&D yet. Also this case is reproducible for pages online only. 382944 3 88954 eric 2011-04-10 15:40:34 -0700 Comment on attachment 88954 Patch for review How do we test this? 383103 4 benjamin 2011-04-11 04:57:45 -0700 (In reply to comment #3) > (From update of attachment 88954 [details]) > How do we test this? That is quite a problem. I looked at testing drag-and-drop last week and we have big issue because of the way Qt handle drag and drop. Currently, we do not run the layout tests. :( 383134 5 eric 2011-04-11 06:17:34 -0700 In general things which aren't tested are broken. So I think it is probably more worth your time to fix the drag and drop testing on Qt... then at least you'll know what's broken there in comparison to other ports. :) 393165 6 88954 kling 2011-04-26 17:17:45 -0700 Comment on attachment 88954 Patch for review Just tested this on Safari and Chromium, and the test doesn't work on either of them. We should not be adding different behavior for QtWebKit. 396253 7 aparna.nand 2011-05-01 23:19:52 -0700 This is broken on all the ports because, we dont allow getData to be called when drag start or drag over is happening. This is for security reason, that getData can be accessed only during drop event and not before that. This so, because when you are dragging data across documents on your desktop, you do not want getData to be called by intermittent document which is not suppose to have access to data. The real solution to this problem would be to check if the dragging is happening within the same document (if within same domain), then getData can be accessed in drag enter and drag over event too. This is the implementation in other browsers like firefox. 488973 8 rhemalinder 2011-10-22 17:15:14 -0700 This is a huge problem for me (see http://stackoverflow.com/questions/7830249/how-do-you-get-the-selected-items-from-a-dragstart-event-in-chrome-is-datatrans) this solution makes perfect sense. For example, a dragstart should have the data being dragged available if the event is registered on that document. E.G. Add this to the Chrome Javascript dev console... window.addEventListener("dragstart", function(event) { alert(event.dataTransfer.getData("Text")); }); Returns alerts 'undefined' when selected text is dragged. :( (In reply to comment #7) > This is broken on all the ports because, we dont allow getData to be called when drag start or drag over is happening. This is for security reason, that getData can be accessed only during drop event and not before that. This so, because when you are dragging data across documents on your desktop, you do not want getData to be called by intermittent document which is not suppose to have access to data. The real solution to this problem would be to check if the dragging is happening within the same document (if within same domain), then getData can be accessed in drag enter and drag over event too. This is the implementation in other browsers like firefox. 975196 9 jturcotte 2014-02-03 03:17:30 -0800 === Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines. 88954 2011-04-10 11:11:34 -0700 2011-04-26 17:17:45 -0700 Patch for review patch_58206 text/plain 1416 aparna.nand ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZwppbmRleCA2Y2FlYjA5Li44MGQ2NmY5IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViQ29y ZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTkg QEAKKzIwMTEtMDQtMTAgIEFwYXJuYSBOYW5keWFsICA8YXBhcm5hLm5hbmRAd2lwcm8uY29tPgor CisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIEhUTUw1IGRy YWcgYW5kIGRyb3Agbm90IHdvcmtpbmcgd2hlbiBnZXREYXRhIGlzIHVzZWQKKyAgICAgICAgaHR0 cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTU4MjA2CisKKyAgICAgICAgZ2V0 RGF0YSBmdW5jdGlvbiB3YXMgZmFpbGluZyBiZWNhdXNlIHRoZSBzZWN1cml0eSBwb2xpY3kKKyAg ICAgICAgc2V0IGlzIGNsaXBib2FyZFR5cGVzUmVhZGFibGUgYW5kIGV4cGVjdGVkIHZhbHVlIGlz IAorICAgICAgICBjbGlwYm9hcmRSZWFkYWJsZS4gVGhpcyB2YWx1ZSBpcyBzZXQgaW4gRHJhZ0Nv bnRyb2xsZXI6OnRyeURIVE1MRHJhZworICAgICAgICBpZiBVUkwgaXMgbm90IGxvY2FsLiBDb3Jy ZWN0ZWQgZm9yIGdldERhdGEgZnVuY3Rpb24gdG8gYWNjZXB0IAorICAgICAgICBjbGlwYm9hcmRU eXBlc1JlYWRhYmxlLiAgCisKKyAgICAgICAgKiBwbGF0Zm9ybS9xdC9DbGlwYm9hcmRRdC5jcHA6 CisgICAgICAgIChXZWJDb3JlOjpDbGlwYm9hcmRRdDo6Z2V0RGF0YSk6CisKIDIwMTEtMDQtMDkg IEtlaXRoIEt5eml2YXQgIDxrZWl0aC5reXppdmF0QG5va2lhLmNvbT4KIAogICAgICAgICBSZXZp ZXdlZCBieSBMYXN6bG8gR29tYm9zLgpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvcGxhdGZv cm0vcXQvQ2xpcGJvYXJkUXQuY3BwIGIvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vcXQvQ2xpcGJv YXJkUXQuY3BwCmluZGV4IDcyM2NkZDQuLmY4ZWJmMDkgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJD b3JlL3BsYXRmb3JtL3F0L0NsaXBib2FyZFF0LmNwcAorKysgYi9Tb3VyY2UvV2ViQ29yZS9wbGF0 Zm9ybS9xdC9DbGlwYm9hcmRRdC5jcHAKQEAgLTE0Myw3ICsxNDMsNyBAQCB2b2lkIENsaXBib2Fy ZFF0OjpjbGVhckFsbERhdGEoKQogU3RyaW5nIENsaXBib2FyZFF0OjpnZXREYXRhKGNvbnN0IFN0 cmluZyYgdHlwZSwgYm9vbCYgc3VjY2VzcykgY29uc3QKIHsKIAotICAgIGlmIChwb2xpY3koKSAh PSBDbGlwYm9hcmRSZWFkYWJsZSkgeworICAgIGlmIChwb2xpY3koKSAhPSBDbGlwYm9hcmRSZWFk YWJsZSAmJiBwb2xpY3koKSAhPSBDbGlwYm9hcmRUeXBlc1JlYWRhYmxlKSB7CiAgICAgICAgIHN1 Y2Nlc3MgPSBmYWxzZTsKICAgICAgICAgcmV0dXJuIFN0cmluZygpOwogICAgIH0K