| Summary: | Clipboard interferes with gtk entry completion, causing unintentional acceptance of inline suggestion | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | gkatev <george_kate> |
| Component: | Clipboard widget & pop-up | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | ilmari.lauhakangas, kdedev, nate, qydwhotmail, tomashnyk |
| Priority: | NOR | ||
| Version First Reported In: | 6.4.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| URL: | https://bugzilla.gnome.org/show_bug.cgi?id=333320 | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Video showing the issue | ||
Thanks for the bug report, and the video that clearly shows the problem. I'm able to reproduce this with Plasma built from git-master, using Nemo and the steps in the video Related reports elsewhere: https://bugzilla.gnome.org/show_bug.cgi?id=333320 https://bugs.documentfoundation.org/show_bug.cgi?id=169105 LibreOffice just got a workaround for the issue. Would people please try with https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6956 (if you can build plasma-workspace - in theory a few commands from https://develop.kde.org/docs/getting-started/building/kde-builder-setup/ and a few hours should be enough :-)) This bug is a bit tricky to reproduce, but I think I was able to reproduce it fairly reliably with Gnome open dialog and from home typing .local/share/akonadi - at akonadi, it would usually trigger, but with this MR, I can no longer do that. But would love others to test. Hi, thanks for the input. Unfortunately I can still reproduce the problem with MR 6956 applied (I used v6.7.4 though, not master). I also added a printf inside, to make sure I got it right. Can you share a bit more about the possible relevance of that PR with this issue? I tried some very quick&dirty debugging, and do generally see setMimeDataInternal() getting called for every character typed, with selectionMimeData. Does this say anything? Anything else I could try out? By the way, I don't have "Keep the selection and clipboard the same" enabled, if that's relevant. I set NoEmptyClipboard=false in .config/klipperrc and the issue went away for me. Does this sound right? And if yes, does it mean that the 'Prevent empty clipboard' feature is inherently contradictory for this, or just that its implementation needs adjusting? Hm, then I suspect the underlying issue might be the same as here: https://bugs.kde.org/show_bug.cgi?id=506325#c16 There, touching the codepaths that fire when emptyclipboard is detected solves the issue, which mirros what you experience (and there indeed the problem is that selection in GTK, a new event is fired for every character (de)selected and when you unselect all, it also tries to empty the primary clipboard (which is why NoEmptyClipboard=false - what that does needs to be changed for when the clipboard entry comes from selection). I should have a patch ready in at most a week (I suspect the proper fix might a bit bigger refactor than just a few lines, though a rudimentary patch I have solves the other issue already). That my MR could solve that was just a hunch - and it seemed to solve it for me. It touches how selection is signalled, but if it has not fixed it for you, might hunch was wrong and maybe I am somehow triggering it differently than you. |
Created attachment 185307 [details] Video showing the issue SUMMARY The clipboard somehow interferes with (gtk) entry fields, resulting in premature/unprompted acceptance of gtk autocomplete suggestions. I can reliably reproduce this in multiple applications (e.g. GTK file open dialog, nemo file manager path input field). Erasing the clipboard history or disabling it entirely makes the issue go away STEPS TO REPRODUCE 1. Enable the clipboard thingy, and copy some text. 2. Open a GTK application that has a field which supports auto completion. I use nemo in the video, you could also use the GTK file chooser dialog (Ctrl+L to enter a path). 3. Start typing a file path, which does exist, and has at least a couple characters unique compared to other files in the same directory (so that the inline completion will trigger). 4. Keep typing in the path, at some point the inline completion suggestion will show up. It will fill in the rest of the path for you, but the part it filled in will be selected, so that any new characters you type replace the selection. 5. Continue typing the path without accepting the suggestion using the Tab key. 6. At some point, the suggestion will be accepted for you, the cursor moves forward and the text is unselected. If it doesn't immediately occur, try it again a couple times. Try giving it a bit of speed too. 7. Erase the entire clipboard history, and try the whole process again. The problem goes away and the suggestion won't be accepted as long as you don't press the Tab key. * See also the video IMPACT You try to type a path like "~/.local". Midway through typing it the inline suggestion is accepted against your wishes, and you end up with "~/.local/al". SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.18.0 Qt Version: 6.9.2