3 ms·

> For firefox running in Wayland, `writeXPrimary()` will only succeed when the firefox window (the main window, not necessarily the tab the code runs in) has th

> For firefox running in Wayland, `writeXPrimary()` will only succeed when the firefox window (the main window, not necessarily the tab the code runs in) has the focus. Otherwise the selection will be cleared. At first I assumed that this is something specific to the Wayland protocol, but that turned out to be utterly false; it's just some quirk, bug or "feature" specific to either firefox itself or GTK. Most Wayland compositors will refuse clipboard requests from unfocused clients. Additionally, the Wayland protocol carries an event identifier, so that the compositor can tie the clipboard request to a pointer/keyboard/touch event and take a better decision. (This metadata is missing for X11 clients, of course.)

kelnos 3y ago
> Additionally, the Wayland protocol carries an event identifier, so that the compositor can tie the clipboard request to a pointer/keyboard/touch event and take a better decision. That's actually not the case. There's a serial number that the client provides when they want to set the selection (that is, cut/copy)[0][1], but nothing when a client requests a paste[2][3]. I always thought this is weird; while yes, it's nice to prevent random applications from spuriously taking over as the source of the clipboard/primary, I think it's much more important to have a mechanism to reduce the risk of a client pasting without permission. [0] https://wayland.app/protocols/wayland#wl_data_device:request:set_selection https://wayland.app/protocols/wayland#wl_data_device:request... (regular clipboard) [1] https://wayland.app/protocols/primary-selection-unstable-v1#zwp_primary_selection_device_v1:request:set_selection https://wayland.app/protocols/primary-selection-unstable-v1#... (primary selection) [2] https://wayland.app/protocols/wayland#wl_data_offer:request:receive https://wayland.app/protocols/wayland#wl_data_offer:request:... (regular clipboard) [3] https://wayland.app/protocols/primary-selection-unstable-v1#zwp_primary_selection_offer_v1:request:receive https://wayland.app/protocols/primary-selection-unstable-v1#... (primary selection)
- emersion 3y ago
  By "clipboard request", I meant "request to set the clipboard".
  - kelnos 3y ago
    Heh, just noticed your username, obviously you know what you're talking about. I also misinterpreted what this issue was about; my mental assumption of "pastejacking" is when a malicious app grabs the (possibly sensitive) clipboard contents without the user knowing about it (which the Wayland protocol doesn't protect against via a serial number in the request)... but that's the opposite of this issue. And you're right, in this case a compositor could absolutely reject Firefox's set_selection() request here since any serial passed to it would probably be out of date. And correct me if I'm wrong, but IIRC wlroots does make an effort to check that the serial passed is current enough.

kelnos 3y ago

> Additionally, the Wayland protocol carries an event identifier, so that the compositor can tie the clipboard request to a pointer/keyboard/touch event and take a better decision. That's actually not the case. There's a serial number that the client provides when they want to set the selection (that is, cut/copy)[0][1], but nothing when a client requests a paste[2][3]. I always thought this is weird; while yes, it's nice to prevent random applications from spuriously taking over as the source of the clipboard/primary, I think it's much more important to have a mechanism to reduce the risk of a client pasting without permission. [0] https://wayland.app/protocols/wayland#wl_data_device:request:set_selection https://wayland.app/protocols/wayland#wl_data_device:request... (regular clipboard) [1] https://wayland.app/protocols/primary-selection-unstable-v1#zwp_primary_selection_device_v1:request:set_selection https://wayland.app/protocols/primary-selection-unstable-v1#... (primary selection) [2] https://wayland.app/protocols/wayland#wl_data_offer:request:receive https://wayland.app/protocols/wayland#wl_data_offer:request:... (regular clipboard) [3] https://wayland.app/protocols/primary-selection-unstable-v1#zwp_primary_selection_offer_v1:request:receive https://wayland.app/protocols/primary-selection-unstable-v1#... (primary selection)

emersion 3y ago
By "clipboard request", I meant "request to set the clipboard".
- kelnos 3y ago
  Heh, just noticed your username, obviously you know what you're talking about. I also misinterpreted what this issue was about; my mental assumption of "pastejacking" is when a malicious app grabs the (possibly sensitive) clipboard contents without the user knowing about it (which the Wayland protocol doesn't protect against via a serial number in the request)... but that's the opposite of this issue. And you're right, in this case a compositor could absolutely reject Firefox's set_selection() request here since any serial passed to it would probably be out of date. And correct me if I'm wrong, but IIRC wlroots does make an effort to check that the serial passed is current enough.