Closed onlyreportingissues closed 4 months ago
This also sometimes happens copying from cosmic-term to itself. Until it's moved out of the stack. But it works after moving it back.
I'm not sure exactly what the pattern of when it works and doesn't is.
It seems this is reproducible by opening two cosmic-term windows and putting them in a stack.
It is only possible to copy to one of the windows, including from itself. (Unlike Firefox, which handles that copy internally.) It is possible to paste into either window. The behavior is clearer to understand when Firefox isn't involved.
It looks like we're allowing any client in the focused stack to set the clipboard? Since that uses client_of_object_has_focus
to test which client has keyboard focus, which uses same_client_as
, which for CosmicMappedInternal::Stack
, we implement as s.surfaces().any(|w| w.same_client_as(object_id))
. Presumably we'll want to restrict that to only the active window in the stack. Not sure if anything else would rely on this all
behavior of same_client_as
.
This isn't the issue here, but could cause bugs or security problems, so it's something to address.
It seems the problem is simply that set_data_device_focus
isn't called when the active element of the stack is changed, so the previous active element stays the same. Since KeyboardFocusTarget
contains the whole stack, and not the single window, and isn't changed here, SeatHandled::focus_changed
isn't called.
So the issue isn't really that complicated, but can have somewhat weird effects. Somehow we'll need to make sure that changes to the active member of a stack always set the data device focus, if the stack has keyboard focus.
E.g. copying a text from a stacked Firefox tab to the stacked cosmic-term tab & vice versa.