Paste stops working on Linux after a while

Issue type

UX/Interaction bug (incorrect behaviour)

Description with steps to reproduce

1. Create/open some score
2. edit, cut, paste as expected - a couple of times
3. ... just to find that after some irreproducible time, "paste" does not work any more
4. ... no matter whether by ctrl-C / ctrl-V or by edit-menue
5. trying to pin down reproducibility, find that it is actually "copy" that does not work
6. find the dreaded "QXcbClipboard::setMimeData: Cannot set X11 selection owner" on the console I started Musescore from
7. restarting MuseScore4 (all instances) restores working clipboard for a couple of cut&pastes / minutes
8. Try with Flatpack Version (I think it was 4.3?), same issue
9. The issue does NOT occur with MS 3.2.3 from debian package (Qt 5.15.15)
10. I have similiar issues with some(any?) other qt6 applications (octave, Dolphin)

System environment:
MuseScore-Studio-4.6.5.253511702-x86_64.AppImage
on debian trixie 13.3

Supporting files, videos and screenshots

When I try to add a diagnostic file, github respones

<!-- Failed to upload "MS_4-6-5_clip-crash_2026-02-13.zip" -->

In which versions of MuseScore Studio is this issue present?

4.6.5 and earlier

Regression

Yes, this used to work in MuseScore 3.x and now is broken

Operating system

debian trixie 13.3

Additional context

A web search reveals that "QXcbClipboard::setMimeData: Cannot set X11 selection owner" was a dreaded timing / race condition issue with qt5 on X11. Reads like in that old times, "culprit" was distributed between X11, qt implementation, system configuration and some apps not precisely sticking to the rules in all cases.
Debuggers night mare, so to say. Do we face some qt regression bug here?

My feeling is that probability of clipboard crashes increases when I try to repair corrupt files, e.g. as produced by audiveris scanner. May I guess that corrupt files trigger code pathways that are not really finetuned?

On the other hand, even large partitions created from scratch in Musescore4.6.5 may be edited for an hour or so without need for a restart to restore a working clipboard.

Checklist

• This report follows the guidelines for reporting bugs and issues
• I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
• I have attached all requested files and information to this report
• I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

Start by reproducing the clipboard failure on Debian trixie with MuseScore Studio 4.6.5, using the reported cut/copy and paste steps. Capture the QXcbClipboard error and compare behavior between the Qt 6-based MuseScore build and MuseScore 3.2.3 with Qt 5.15.15. Done means identifying a reproducible cause or a confirmed fix for clipboard ownership loss.