Currently, Firefox will stuck in "dnd" mode if you try to drag any of
its tabs. The main reason for that is that kwin doesn't send the
wl_data_source.cancelled event if the pointer button has been released
and there is no target surface or if the data source hasn't been
accepted by anyone.
CCBUG: 427528
This was done mostly because I wanted to get rid of the Resource
dependency in AbstractDataSource so I can make our xwl bridge direct,
but this also fixes up some issues with object lifespan present in the
previous version and keeps all our clipboard code in-line.
The source can have a different lifespan to the offer being made.
If a source is removed and we get a drag actions changed before the
offer is cancelled we don't want to crash.
Couldn't reproduce locally, but the trace was good.
BUG: 423127
Summary:
Clipboard managers and middle click paste are new protocols.
We want to be able to copy from a clipboard manager to a regular
clipboard and vice versa without duplicating loads of code.
If we support kliper's "syncronise contents of the clipboard and
selection" inside the compositor that would become an unmanageable amount
of combinations.
It also potentially allows the idea of our XWayland bridge not being a
wayland client and simplifying that code.
Test Plan: Unit test passes
Reviewers: #kwin
Subscribers: zzag
Differential Revision: https://phabricator.kde.org/D29329
Summary:
A DataDevice will have zero or one active DataSource as the seclection.
In the existing code we track the current data device then update it to
the newest data device
when the source inside a data device changes.
If we store the active data source inside Seat instead of the device
everything becomes
somewhat simpler and safer.
An entire unit test vanishes as that case of an externally set
DataDevice with no source
can no longer happen.
There's also a lot of duplication that's been merged in this patch so we
have one path.
There are some technical behavioural changes in particular we do cleanup
when the
source vanishes rather than the data device, but if anything that seems
safer and more correct.
It's a precursor for introducing an abstraction class round the source
without needing to meddle
with too much code.
Test Plan: Relevant unit tests passed, ran with it for a while with no
issue.
Reviewers: #kwin
Differential Revision: https://phabricator.kde.org/D29328
Summary:
proxyRemoteSurface is a fake wayland surface created for the drag and
drop between X and wayland clients.
The lifespan is not guaranteed to outlive the DataDevice.
Kwin closes Xwl before the other wayland client connections so it's
technically dangling for a bit when events could be dispatched.
Probably will never happen, but better to guard and be safe.
Test Plan: Compiles
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D22862
Summary:
Allows a compositor to set a proxy surface to handle drag and drop
operations place of the actual surface the drag originated from.
One proxy surface can handle multiple origin surfaces at the same time. These
need to get registered once. The active remote surface gets set when a pointer
button is pressed on the surface.
Test Plan: Manually with KWin's Xwayland DnD patches.
Reviewers: #kwin
Subscribers: davidedmundson, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D15421
Summary: An internal drag is without data source. Still we tried to create offers.
Test Plan: This change makes the updated autotest in D15072 pass without errors.
Reviewers: #kwin, hein
Reviewed By: hein
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D15074
Summary:
A drag start request should be dismissed when the client does not have an
implicit pointer grab or the currently focused pointer surface is not the
origin. The conditions for that were wrong in the past.
Also just ignore the request and not post directly an error, that potentially
kills the client since by concurrency the client might have send a valid
request, that got invalidated through grab or focus change at the same time
on the server side.
Test Plan: Manually and autotest.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: adridg, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D15072
Summary:
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
Test Plan: Patch provided by the reporter, he reported success.
Reviewers: #plasma, #frameworks, romangg
Reviewed By: #plasma, romangg
Subscribers: michalsrb, romangg, graesslin, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D13535
Summary:
This addresses the following situation:
1. Start drag on a QtWayland based window
2. Press escape
3. Release mouse
-> this results in a crash. The main reason for this is that QtWayland
destroys the DataSource in step 2 and KWayland did not expect this at
all. The drag and drop operation continued and results in step 3 in the
drag target to request data from the no longer existing DataSource.
This change addresses the root of the problem by cancelling the drag
operation when the DataSource gets destroyed.
BUG: 389221
FIXED-IN: 5.44
Test Plan:
New test case exposing the problem and manual testing with
kwin_wayland and dolphin (based on bug report)
Reviewers: #frameworks, #kwin, #plasma
Subscribers: plasma-devel
Tags: #frameworks, #plasma
Differential Revision: https://phabricator.kde.org/D10142
We should only enforce the check whether a data source has set the
actions for drag on drop on a selection if it's at least version 3. For
backward compatibility we used to set a default action which would
ensure that a version <3 and >3 client can interact with each other. But
due to that the action was set to a default value which breaks any
selection. Sorry about that.
This change ensures the backward compatibility behavior does not break
selection.
As the regression causes all clients to quit it is a severe regression
which requires fast action. Due to that I'm doing a maintainer push
without review. I encourage everyone to do a post commit review.
Sorry for not noticing the regression before. The backward compatibility
was the last thing I added in that patch set and apparently I did not
run all tests again.
Summary:
The main difference compared to version 2 is additional drag and drop
actions. The source and destination can negotiate whether the data
should be copied or moved or the user should be asked for either or.
This seems to be important for GTK, but is not yet implemented in Qt.
The main motivation for adding support is that it is required by SDL to
launch on Wayland.
BUG: 386993
Test Plan: Extended test case, sdl apps now start
Reviewers: #frameworks, #plasma, #kwin
Subscribers: plasma-devel
Tags: #plasma_on_wayland, #frameworks
Differential Revision: https://phabricator.kde.org/D9136
Summary:
A DataDevice will have a source when offers are available, but it can
also be legitimately cleared.
When calling DataDeviceInterface::sendSelection(DataDeviceInterface
*other) if the other data device has no source, we should be setting
that we also have no source.
In addition this also guards against Seat tracking a DataDeviceInterface
with no source when trying to sync x clipboards.
BUG: 383054
Reviewers: #plasma
Subscribers: graesslin, plasma-devel, #frameworks
Tags: #plasma_on_wayland, #frameworks
Differential Revision: https://phabricator.kde.org/D7316
Summary:
According to the Wayland documentation a data source needs to be
cancelled whenever it is no longer valid. A reason for no longer being
valid is that the data source has been replaced by another data source.
So far KWayland did not implement this aspect which resulted in clipboard
breaking in QtWayland applications. As soon as one copied once from an
application it was no longer possible to paste to it from another
application.
With this change the data source gets properly cancelled and also
ensured that the server code doesn't run into a possible crash condition
when trying to cancel an already unbound data source.
BUG: 368391
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D2743
Summary:
So far for internal cleanup we mostly listen to QObject::destroyed.
When a Resource gets unbind the wl_resource is set to null and the
Resource gets deleteLater. This creates a short time frame when the
Resource is still there, but the wl_resource is null. For most internal
usages the Resource is completely useless at that point and should no
longer be considered. So far it was still considered and could hit
crashers, if a code path did not nullptr check. Unfortunately
libwayland-server is not nullptr safe: if called with a null value it
tends to crash.
So this check introduces a new signal unbound which can be listend to
in addition to the destroyed signal. It's used in SeatInterface for
DataDeviceInterface, where we experienced a crash related to that.
A test case is added which exposes the crash, but it already needs
the unbound signal to get into the crashy condition. The actual crash
is fixed twice - with the help of the unbound signal, but also by
introducing the nullptr check where it's needed.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D1868
Summary:
This change standardizes the behavior regarding the destructor request.
The destructor should destroy the resource and nothing else. The
Wayland library invokes the static unbind method once the resource is
destroyed. The implementation provided by Resource::Private::unbind
triggers a delete later on the Resource. So there is no need to trigger
a deleteLater from the destructor request callback.
This change adds a generic implementation to Resource::Private which is
now used by all inheriting classes replacing the custom implementations.
Test Plan:
For a few Resources the test is extended to ensure that the Resource
gets deleted on server side.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1679
Summary:
How drag'n'drop works on Wayland:
When a surface has a pointer grab and a button pressed on the surface
(implicit grab) the client can initiate a drag'n'drop operation on the
data device. For this the client needs to provide a data source
describing the data to be transmitted with the drag'n'drop operation.
When a drag'n'drop operation is active all pointer events are interpreted
as part of the drag'n'drop operation, the pointer device is grabbed.
Pointer events are no longer sent to the focused pointer but to the
focused data device. When the pointer moves to another surface an
enter event is sent to a data device for that surface and a leave
event is sent to the data device previously focused. An enter event
carries a data offer which is created from the data source for the
operation.
During pointer motion there is a feedback mechanism. The data offer
can signal to the data source that it can or cannot accept the data
at the current pointer position. This can be used by the client being
dragged from to update the cursor.
The drag'n'drop operation ends with the implicit grab being removed,
that is the pressed pointer button which triggered the operation gets
released. The server sends a drop event to the focused data device.
The data transfer can now be started. For that the receiving client
creates a pipe and passes the file descriptor through the data offer
to the sending data source. The sending client will write into the
file descriptor and close it to finish the transfer.
Drag'n'drop could also be initiated through a touch device grab, but
this is not yet implemented.
The implementation in this change focuses on the adjustments for pointer.
For the user of the library drag'n'drop is implemented in the
SeatInterface. Signals are emitted whenever drag is started or ended.
The interaction for pointer events hardly changes. Motion, button press
and button release can still be indicated in the same way. If a button
release removes the implicit grab the drop is automatically performed,
without the user of the library having to do anything.
The only change during drag and drop for the library user is that
setFocusedPointerSurface is blocked. To update the current drag target
the library user should use setDragTarget. Sending the enter/leave to the
data device gets performed automatically.
The data device which triggered the drag and drop operation is exposed
in the SeatInterface. The user of the library should make sure to render
the additional drag icon provided on the data device. At least QtWayland
based applications will freeze during drag and drop if the icon doesn't
get rendered.
The implementation is currently still lacking the client side and due to
that also auto test. It's currently only tested with QtWayland clients.
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1046
The selection is supposed to be sent to the DataDeviceInterface just
before getting keyboard focus. In order to do that the SeatInterface
keeps track of the DataDeviceInterface which is the current selection
and the DataDeviceInterface of the focused keyboard client.
SeatInterface friends DataDeviceManagerInterface so that the latter
can register each created DataDevice for the SeatInterface.
There can only be one focused surface per Seat, thus the information
should be hold in the seat.
This only adjusts the API, the actual data is still hold in the
PointerInterface. This still needs adjustment.
Required information is passed through the ctor of Private.
::create is still virtual as ShellSurfaceInterface is retrieving
client information. This can be fixed once we have a better wl_client
encapsulation class.
The Resource base class is supposed to be used by all interface
classes which get created for a wl_resource.
Most interface classes are adjusted, but there are some exceptions:
* BufferInterface: is different as the wl_resource is already created
* PointerInterface and KeyboardInterface: those two need changes, the
implementation differs from all other interface implementations.
Only selection part is implemented, drag'n'drop still needs to be
implemented.
Unit test is not properly testing whether the data can be transferred.
This needs some better architecture to have multiple processes which
perform the source and target part.
