Open Bug 1719036 Opened 3 years ago Updated 3 years ago

In multiseat mode of sway, pasting in firefox use clipboard data from the wrong seat.

Categories

(Core :: Widget: Gtk, defect, P3)

Firefox 89
defect

Tracking

()

UNCONFIRMED

People

(Reporter: panawat_vista, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

  1. Plug in two sets of keyboards and mice
  2. Attach the second set of keyboard and mouse to a new seat (e.g. seat1) in the sway configuration file. e.g.:
    seat seat1 attach 9390:6163:RAPOO_Rapoo_2.4G_Wireless_Device
    seat seat1 attach 9390:6163:RAPOO_Rapoo_2.4G_Wireless_Device_Consumer_Control
    seat seat1 attach 9390:6163:RAPOO_Rapoo_2.4G_Wireless_Device_Mouse
  3. Restart sway
  4. Execute
    wl-copy -s seat0 's0m';
    wl-copy -s seat1 's1m';
    wl-copy -p -s seat0 's0p';
    wl-copy -p -s seat1 's1p';
    firefox;
  5. Then try pasting, using both keyboards and both mice in firefox

Actual results:

When pasting using the keyboard or mouse from either seat, only 's1p' or 's1m' are pasted depending on whether you paste it using a middle click or not.
No 's0p' or 's0m' are ever pasted.

Expected results:

When using the seat0's keyboard and mouse,
pasting should give 's0m' or 's0p'.
And when using the seat1's, it should gives 's1m' or 's1p'.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
You need to log in before you can comment on or make changes to this bug.