| Summary: | Pasting multiline text from Firefox results in double new lines between each text block | ||
|---|---|---|---|
| Product: | [Applications] konsole | Reporter: | Henrik Hudson <rhavenn> |
| Component: | copy-paste | Assignee: | Konsole Developer <konsole-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | a.samirh78, fjveas, i, kde, rdieter, scott |
| Priority: | NOR | ||
| Version: | 20.04.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/utilities/konsole/commit/6b6a1e552492a25217cded1d83c25a652e5b249a | Version Fixed In: | 20.04.3 |
| Sentry Crash Report: | |||
|
Description
Henrik Hudson
2020-05-13 19:12:01 UTC
Can confirm and reproduce at Arch Linux w/ Plasma 5.19.0, Frameworks 5.70.0 and Qt 5.15.0. Git commit a1022442dc2f59321976fd3456ad97c61300d1f2 by Ahmad Samir. Committed on 15/06/2020 at 20:29. Pushed by ahmadsamir into branch 'master'. Don't add extra newlines when pasting from GTK applications Due to some internal handling in GTK itself, we end up with text copied from Firefox where a newline is represented as CRLF (\r\n); since the doPaste() method replaces each \n with \r, we ended up with \r\r, which ultimately led to extra newlines in the pasted code. To fix the issue simply detect the CRLF case and replace each \r\n with \r. To test, copy some multiline text from Firefox, open vim in konsole and paste, you end up with two newlines between each block of text. Compare the results after applying this patch FIXED-IN: 20.08 M +4 -0 src/TerminalDisplay.cpp https://invent.kde.org/utilities/konsole/commit/a1022442dc2f59321976fd3456ad97c61300d1f2 *** Bug 423201 has been marked as a duplicate of this bug. *** As you see in my bug report Bug 423201 at the "xclip -o|hexdump" output, I sometimes get 0a0d in the clipboard which would be the reverse case of what is fixed here: linefeed and then carriage return, so your fix would actually not solve that issue. Maybe posting to vim works (but it should actually not either), but posting directly a set of sample commands (like the multiple echo block from reddit I mention) into Konsole will still create the unexpected results. Shouldn't we also detect the \n\r case and replace that with a single \r? This reverse \n\r seem to only happen when you turn on "synchronize contents of the clipboard and the selection" and really make a copy (ctrl-c) of your selection in Firefox. Shall I re-open my original bug or file one for klipper? I still think it would be an easy fix in the terminal itself, again it only influences konsole - all other terminals I tested can cope even with the reverse lfcr. I'll reopen the other bug so that it's not forgotten, and then we can investigate further whether it's the same issue or a different one. Interesting about the \n\r (it makes sense to also replace \n\r with \r... but better look at klipper code first). Thanks for persisting with the report (I missed the \n\r bit, sorry about that). Git commit 6b6a1e552492a25217cded1d83c25a652e5b249a by Kurt Hindenburg, on behalf of Ahmad Samir. Committed on 19/06/2020 at 14:49. Pushed by hindenburg into branch 'release/20.04'. Don't add extra newlines when pasting from GTK applications Due to some internal handling in GTK itself, we end up with text copied from Firefox where a newline is represented as CRLF (\r\n); since the doPaste() method replaces each \n with \r, we ended up with \r\r, which ultimately led to extra newlines in the pasted code. To fix the issue simply detect the CRLF case and replace each \r\n with \r. To test, copy some multiline text from Firefox, open vim in konsole and paste, you end up with two newlines between each block of text. Compare the results after applying this patch FIXED-IN: 20.04.3 (cherry picked from commit a1022442dc2f59321976fd3456ad97c61300d1f2) M +4 -0 src/TerminalDisplay.cpp https://invent.kde.org/utilities/konsole/commit/6b6a1e552492a25217cded1d83c25a652e5b249a *** Bug 423201 has been marked as a duplicate of this bug. *** *** Bug 424130 has been marked as a duplicate of this bug. *** |