GNOME Bugzilla – Bug 759626
Clipboard (copy-and-paste) Wayland→Wayland or Wayland→X11 from closed applications is broken
Last modified: 2018-05-02 16:52:19 UTC
Steps to reproduce: 0. run a gnome+wayland session 1. open gedit (or any other Gtk+ 3.x application, e.g. gnome-builder) with wayland backend 2. open any file 3. copy some text 4. close gedit 5. open gedit (or gtk3 application; new instance) with wayland or x11 backend 6. paste text What happens: Doesn't paste text at all. No error or warning messages. Affected software versions: gtk3-3.18.6-1.fc23.x86_64 gedit-3.18.2-1.fc23.x86_64 gnome-builder-3.18.1-2.fc23.x86_64 glib2-2.46.2-1.fc23.x86_64 Additional info: This could also be an issue in mutter or wayland. It can also be reproduced in a weston wayland session.
Carlos, can we have data remaining after a client is gone? The selection data offer ends with the client, doesn't it?
(In reply to Olivier Fourdan from comment #1) > Carlos, can we have data remaining after a client is gone? The selection > data offer ends with the client, doesn't it? Yes, there is currently no equivalent of a clipboard manager in Wayland. But there's fundamentally no reason it couldn't exist. That role would belong to mutter, of course. We would need to add a Wayland request that says "hey compositor, eat my clipboard now please and thank you," probably wl_data_source::store with no parameters. I think that would probably be upstreamable. Then, trigger that from gtk_wayland_display_store_clipboard() and flip the return value of gdk_wayland_display_request_selection_notification(). mutter would then drain the wl_data_source (triggering wl_data_source::send in the client) for each supported MIME type (inefficient, but that's the nature of clipboard managers, right?), and use it to respond to any future wl_data_offer::receive requests from other clients. We really ought to do something along these lines sooner or later, as users do not expect clipboard data to disappear when an app is closed.
(In reply to Michael Catanzaro from comment #2) > (In reply to Olivier Fourdan from comment #1) > > Carlos, can we have data remaining after a client is gone? The selection > > data offer ends with the client, doesn't it? > > Yes, there is currently no equivalent of a clipboard manager in Wayland. There is one in weston. See https://cgit.freedesktop.org/wayland/weston/tree/src/clipboard.c > But > there's fundamentally no reason it couldn't exist. That role would belong to > mutter, of course. We would need to add a Wayland request that says "hey > compositor, eat my clipboard now please and thank you," probably > wl_data_source::store with no parameters. I think that would probably be > upstreamable. Why would there be a need for a new request? Is it for making the client control what selections would be more "persistent" than others or something? Otherwise, it should work already, the way same clipboard.c in weston works. > Then, trigger that from gtk_wayland_display_store_clipboard() > and flip the return value of > gdk_wayland_display_request_selection_notification(). mutter would then > drain the wl_data_source (triggering wl_data_source::send in the client) for > each supported MIME type (inefficient, but that's the nature of clipboard > managers, right?), and use it to respond to any future > wl_data_offer::receive requests from other clients. We really ought to do > something along these lines sooner or later, as users do not expect > clipboard data to disappear when an app is closed. If we want to have more explicit clipboard manager support (such as a "store" request) that should probably added as an extension ala "wp_clipboard_manager".
(In reply to Jonas Ådahl from comment #3) > Why would there be a need for a new request? Is it for making the client > control what selections would be more "persistent" than others or something? > Otherwise, it should work already, the way same clipboard.c in weston works. Oooh, didn't know about this. Yeah, it's clearly not necessary if we store selection data automatically... my mind jumped to it because it's required in ICCM. So we can avoid this complexity. The original purpose of the separate store request was to avoid unnecessary clipboard IPC overhead, but it's surely not relevant in 2016.
(In reply to Michael Catanzaro from comment #4) > (In reply to Jonas Ådahl from comment #3) > > Why would there be a need for a new request? Is it for making the client > > control what selections would be more "persistent" than others or something? > > Otherwise, it should work already, the way same clipboard.c in weston works. > > Oooh, didn't know about this. > > Yeah, it's clearly not necessary if we store selection data automatically... > my mind jumped to it because it's required in ICCM. So we can avoid this > complexity. > > The original purpose of the separate store request was to avoid unnecessary > clipboard IPC overhead, but it's surely not relevant in 2016. We will want an explicit Store for the same reasons it is necessary in X: You don't want a clipboard manager eagerly collecting megabytes of data because you happened to hit Ctrl-A in a big spreadsheet.
And yes, its still relevant
(In reply to Matthias Clasen from comment #5) > (In reply to Michael Catanzaro from comment #4) > > (In reply to Jonas Ådahl from comment #3) > > > Why would there be a need for a new request? Is it for making the client > > > control what selections would be more "persistent" than others or something? > > > Otherwise, it should work already, the way same clipboard.c in weston works. > > > > Oooh, didn't know about this. > > > > Yeah, it's clearly not necessary if we store selection data automatically... > > my mind jumped to it because it's required in ICCM. So we can avoid this > > complexity. > > > > The original purpose of the separate store request was to avoid unnecessary > > clipboard IPC overhead, but it's surely not relevant in 2016. > > We will want an explicit Store for the same reasons it is necessary in X: > You don't want a clipboard manager eagerly collecting megabytes of data > because you happened to hit Ctrl-A in a big spreadsheet. FWIW, one would have to press Ctrl-A then Ctrl-C to actually set the selection (selection here is the Wayland protocol term, not the user interface term). So when would one do a wl_data_device.set_selection() but not a wp_clipboard_manager.store()?
(In reply to Jonas Ådahl from comment #7) > So when would one do a wl_data_device.set_selection() but not a > wp_clipboard_manager.store()? The clipboard manager only ever needs data if the original client is going to quit or crash. If we do not tolerate data loss when the client crashes, then I suppose we always have to do wp_clipboard_manager.store() and it serves no useful purpose. I think it's reasonable to tolerate clipboard data loss if the application crashes (i.e. if the application is broken). Then GTK+ need only use wp_clipboard_manager.store() when it's quitting (and would hang around long enough to finish that operation after hiding its window). That way we don't wind up doing extra IPC except when really needed.
There are some other clipboard ui patterns that would require us maintain a 'history' of past clipboard contents. Not sure if there is interest in implementing a 'shelf' or something like that that you can retrieve your past clips from.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/587.