Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.11.2
-
None
-
-
062f9bf576 (qt/qtdeclarative/dev) 062f9bf576 (qt/tqtc-qtdeclarative/dev) 22de23c4bb (qt/qtdeclarative/6.4) 062f9bf576 (qt/qtdeclarative/wip/material3) 22de23c4bb (qt/tqtc-qtdeclarative/6.4)
Description
When a non-text mime data type is used with the QQuickDragAttached then there is a large risk of corruption.
Simplified example: (I have tried multiple things, but the ones I truly expected to work here were either QByteArray or QVariant)
Drag.mimeData: { "custom/key_type": someCppObject.byteArrayProperty}
DropArea { keys: ["custom/key_type"] onEntered: { drag.accepted = true } onDropped: { //We currently assume that there is only a single drop format! if (drop.formats[0] === "custom/key_type") { cppObj2.drop(drop.getDataAsArrayBuffer("custom/key_type")); drop.acceptProposedAction(); } } }
When stepping in qtdeclarative it seemed to copy the Drag.mimeData perfectly.
However when recieving it the mime data that arrived was completely different! (16 bytes in, 21 out!)
After further looking I found the following in {{QQuickDragAttachedPrivate::startDrag
}}
for (auto it = externalMimeData.cbegin(), end = externalMimeData.cend(); it != end; ++it) mimeData->setData(it.key(), it.value().toString().toUtf8());
This is at least the most likely problem. And should be easy to fix.
In addition to this it is annoying that it is impossible to directly set/get the mime data, and that it has to be gotten as either a string (text/url etc) or as a ByteArray. Considering the fact that the mime data actually exists on the c++ implementation, and is simply wrapped and hidden away.
Attachments
Issue Links
- relates to
-
QTBUG-93632 Find cross platform solution to QMimeData handling non-mime data
- Closed
- replaces
-
QTBUG-103095 Doc: Drag.mimeData QVariantMap is documented as "stringlist"
- Closed