| romangg |
| Plasma | |
| Frameworks |
GTK applications seem to call wl_data_device::set_selection multiple times with
the same wl_data_source object, replacing it with itself. If we cancel it, they
will destroy it and the selection will be gone.
With this patch it is again possible to copy from GTK applications.
BUG: 395366
Patch provided by the reporter, he reported success.
| No Linters Available |
| No Unit Test Coverage |
| Buildable 10 | |
| Build 10: arc lint + arc unit |
Yes, a unit test makes sense. I tried to add
// replace the data source with itself, ensure that it did not get cancelled
selectionOfferedSpy.clear();
dataSource2->offer(QStringLiteral("text/plain"));
dataDevice->setSelection(1, dataSource2.data());
QVERIFY(selectionOfferedSpy.wait());
QVERIFY(sourceCancelled2Spy.isEmpty());in TestDataDevice::testReplaceSource() and it fails without this patch.
With this patch however, the selection isn't offered (is that correct behaviour?) so the wait() times out.
Is there a better way to test this?
I did some research and yes, it's the correct behavior in my opinion: selectionOffered is emitted on receiving a selection event. According to Wayland documentation:
The selection event is sent out to notify the client of a new wl_data_offer for the selection for this device.
Since there is no new selection the old wl_data_source and wl_data_offer do still exist (selection->cancel() just below your insertion was never called) and a new selection event won't get sent.