On OSes which use X11 as their windowing system, a middle click is supposed to paste the text currently held within the buffer. At some point in the 5.0 series a scrolling feature was added where middle clicking toggles a draggable icon to scroll through the document; this breaks X11 pasting because the middle click is just intercepted. This should work as it does in Chrome/Chromium, where I believe the feature is taken from: you should have to hold down the middle mouse button to scroll, and a click still pastes. Affects Linux, OpenBSD, FreeBSD, NetBSD, DragonflyBSD, any other platform which can make use of X11 pasting; the OS field doesn't allow multiple entries.
(In reply to tekk from comment #0) > At some point in the 5.0 > series a scrolling feature was added where middle clicking toggles a > draggable icon to scroll through the document; This feature was always there. It should be configurable through Tools->Options...->LibreOffice->View->Middle mouse button, but it's indeed seems to be broken now. Tested with today's master under Fedora 22.
That would seem to be the real bug, I just checked and it's just ignoring the setting now, it looks like. Should I close the bug and open a new one for that?
(In reply to tekk from comment #2) > Should I close the bug and open a new one for that? No, let's reuse this bug. Just checked in 4-4 branch, and it works there, so a regression of 5.0.
bibisect result (using lo-linux-dbgutil-daily repository): 929145def84a0b1ea3ddc6b011d6f8e41a279758 is the first bad commit commit 929145def84a0b1ea3ddc6b011d6f8e41a279758 Author: Miklos Vajna <vmiklos@collabora.co.uk> Date: Sat Jun 20 05:49:47 2015 +0200 2015-06-20: source-hash-3ecef8cedb215e49237a11607197edc91639bfcd :100644 100644 000c5fdaa8375e3db5a1cb1885c62c419266cf38 b94f9b4a25ad33e41de70c75a81e84fb1ea03584 M build-info.txt :040000 040000 ab6cc818ec0767b31e4a5e477bc5e15554c2964a 8a42e3a9a83601198477090bea99d5c032baa618 M opt --- $ git bisect log # bad: [6e6e48df3b6eb13cf54223cd1ffac16546ec49c2] 2015-07-17: source-hash-14257152b19c08618a107c6eb0f684de11483da8 # good: [2b392af9c8f54629e3a3a98a8c92fa5af1c6722f] 2015-05-20: source-hash-90e2dabb8d0bb5382234be776c2ad0e2d5d9e224 git bisect start '6e6e48df3b6eb13cf54223cd1ffac16546ec49c2' '2b392af9c8f54629e3a3a98a8c92fa5af1c6722f' # good: [e48eb783142c667bfdad999f0edb90f8253b0b65] 2015-06-18: source-hash-fb6dd2a73074b9695bd8ddf7ba40f1819b03024e git bisect good e48eb783142c667bfdad999f0edb90f8253b0b65 # bad: [cb936e89eced2812e683a84f67099ff12eb97245] 2015-07-02: source-hash-c18f11587d37f285a95447dd8996c8b605732e00 git bisect bad cb936e89eced2812e683a84f67099ff12eb97245 # bad: [12ee5d282ca61a17d52d3ce0ea31ae69fada21b4] 2015-06-25: source-hash-e8938f2ddb5efa8a34d05995cd55cf337c7aaeff git bisect bad 12ee5d282ca61a17d52d3ce0ea31ae69fada21b4 # bad: [2585085ca772383156fa67688430f7b5437af8a3] 2015-06-21: source-hash-d2cefbe7effbee079c05a5a8234305650618fdc1 git bisect bad 2585085ca772383156fa67688430f7b5437af8a3 # bad: [929145def84a0b1ea3ddc6b011d6f8e41a279758] 2015-06-20: source-hash-3ecef8cedb215e49237a11607197edc91639bfcd git bisect bad 929145def84a0b1ea3ddc6b011d6f8e41a279758 # good: [66d7220a7df180fc7b6e7a7f3620d86272c3d838] 2015-06-19: source-hash-ba70050dc37f82306a8a3c5815372a4b9fff18fc git bisect good 66d7220a7df180fc7b6e7a7f3620d86272c3d838 # first bad commit: [929145def84a0b1ea3ddc6b011d6f8e41a279758] 2015-06-20: source-hash-3ecef8cedb215e49237a11607197edc91639bfcd
*** Bug 92889 has been marked as a duplicate of this bug. ***
This impacts us greatly, we have hundreds of users that use the middle mouse to paste each day.
@Dave - if you're running this in a corporate/business setting perhaps you should consider getting paid support - else, you'll have to wait for a volunteer to tackle the issue...that's just how the project works. http://www.documentfoundation.org/certification/developers/
I bisected this bug by building with the the respective commits. Result: 031a347668e56c1b38c0539d30e9a1cbb808ca02 is the first bad commit commit 031a347668e56c1b38c0539d30e9a1cbb808ca02 Author: Caolán McNamara <caolanm@redhat.com> Date: Wed Jun 17 16:25:47 2015 +0100 use gtk3 vclplug by default under GNOME3 if available Change-Id: I4efe8bdfb7080365094306aee9db6b69a7f9e86a :040000 040000 e30d652d2ff1b33a1c47831b6ebd95a134a0f702 14d9ab9c9b05f775af07e7a2fedc9cbbd89b6853 M vcl --- $ git bisect log # bad: [3ecef8cedb215e49237a11607197edc91639bfcd] tdf#83859: Make arrow keys work again in named ranges dropdown # good: [ba70050dc37f82306a8a3c5815372a4b9fff18fc] add test case document to unit tests, tdf#69552 git bisect start '3ecef8cedb215e49237a11607197edc91639bfcd' 'ba70050dc37f82306a8a3c5815372a4b9fff18fc' # bad: [30e87214781dd9ca5830aad674e08354d3f9ae30] optimise SdrObjList::SetObjectOrdNum git bisect bad 30e87214781dd9ca5830aad674e08354d3f9ae30 # bad: [f2a0e4032734d6be635f14ade3dea499c29ec6c2] Don't truncate a UTF-32 code point to a UTF-16 code unit git bisect bad f2a0e4032734d6be635f14ade3dea499c29ec6c2 # bad: [4f1587965e85e09796c2074d90e9067337f2b710] tdf#42374 - read PDF in larger chunks git bisect bad 4f1587965e85e09796c2074d90e9067337f2b710 # good: [e0f3e7c007e9eeced888b491ec2698acba4bc588] tdf#42374 some small optimisations for opening this PDF file git bisect good e0f3e7c007e9eeced888b491ec2698acba4bc588 # good: [4008b6f9bfd919a7435047bc0aedcf7613009809] gtk3: use owner-changed to detect losing/gaining clipboard ownership git bisect good 4008b6f9bfd919a7435047bc0aedcf7613009809 # bad: [031a347668e56c1b38c0539d30e9a1cbb808ca02] use gtk3 vclplug by default under GNOME3 if available git bisect bad 031a347668e56c1b38c0539d30e9a1cbb808ca02 # first bad commit: [031a347668e56c1b38c0539d30e9a1cbb808ca02] use gtk3 vclplug by default under GNOME3 if available
Caolán,could you possibly have a look at this?
In case this should play a role: I am using Debian Jessie with Xfce.
(In reply to Michael Weghorn from comment #8) > I bisected this bug by building with the the respective commits. Result: > > 031a347668e56c1b38c0539d30e9a1cbb808ca02 is the first bad commit > commit 031a347668e56c1b38c0539d30e9a1cbb808ca02 > Author: Caolán McNamara <caolanm@redhat.com> > Date: Wed Jun 17 16:25:47 2015 +0100 > > use gtk3 vclplug by default under GNOME3 if available > > Change-Id: I4efe8bdfb7080365094306aee9db6b69a7f9e86a I can't confirm this. For me it doesn't work even by reverting this change (or just using SAL_USE_VCLPLUGIN=gtk, which is the same thing). My system is Fedora 22 (64-bit) + GNOME Shell.
(In reply to Maxim Monastirsky from comment #11) > I can't confirm this. For me it doesn't work even by reverting this change > (or just using SAL_USE_VCLPLUGIN=gtk, which is the same thing). My system is > Fedora 22 (64-bit) + GNOME Shell. Interestingly, I did revert this commit and built master again and for me, pasting using the middle mouse button worked again afterwards. But if it does not work for you, possibly somebody has to look at this anew...
(In reply to Michael Weghorn from comment #12) > Interestingly, I did revert this commit and built master again and for me, > pasting using the middle mouse button worked again afterwards. But if it > does not work for you, possibly somebody has to look at this anew... I just tested this again and realized that reverting 031a347668e56c1b38c0539d30e9a1cbb808ca02 does not actually fix the bug totally, but somehow to some extent. The behaviour is as follows when I build master (as of commit 9ffdcc76858bc01150727345de4dfd0ef40ed8c0) after reverting this commit: * When I start Writer using the command "instdir/program/soffice --writer", pasting works using the middle mouse button. * When I start Writer using "instdir/program/soffice" and and then selecting "Writer document" in the start center, pasting using the middle mouse button does still not work. If I do not revert this commit, pasting does not work in any of the two cases.
(In reply to Michael Weghorn from comment #13) > * When I start Writer using "instdir/program/soffice" and and then selecting > "Writer document" in the start center, pasting using the middle mouse button > does still not work. That (second bullet point from previous comment) seems to be the way to reproduce the bug that this bug report actually describes. I (bi)bisected again - this time really observing this behaviour. Result: 34b5f862f46930f8c5cce2a908a165db39bbc8dd is the first bad commit commit 34b5f862f46930f8c5cce2a908a165db39bbc8dd Author: Matthew Francis <mjay.francis@gmail.com> Date: Wed May 27 18:00:12 2015 +0800 source-hash-5333782d090a9e147c0c431f0f741863d1d8cf8e commit 5333782d090a9e147c0c431f0f741863d1d8cf8e Author: Noel Grandin <noel@peralex.com> AuthorDate: Mon Jan 12 12:55:32 2015 +0200 Commit: Noel Grandin <noel@peralex.com> CommitDate: Mon Jan 12 12:57:05 2015 +0200 convert SETTINGS_ #defines to 'enum class' and dump the ones that nothing is listening to Change-Id: I253ef284df785812a439dd160edba1b07fdbaac4 :040000 040000 d3914e75319637549ad6b9d9b1754d88e98a7c2d 0769ba0eac6a7b06154c72dc51a2c2d280bd92fe M opt ---- $ git bisect log # bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86 # good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311 git bisect start 'latest' 'oldest' # bad: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d git bisect bad 0c30a2c797b249d0cd804cb71554946e2276b557 # good: [770ff0d1a74d2450c2decb349b62c5087e12c46b] source-hash-549b7fad48bb9ddcba7dfa92daea6ce917853a03 git bisect good 770ff0d1a74d2450c2decb349b62c5087e12c46b # bad: [259e888083cf7697956bb7e5f2691e8153eadb4c] source-hash-1884c0bbd40f0ded41d7a1656cb64fb1f6368c36 git bisect bad 259e888083cf7697956bb7e5f2691e8153eadb4c # bad: [ee7c82541a2e99f76af570d3faa897504149913a] source-hash-54defd1bd3359c95e45891c7294847d0cebca753 git bisect bad ee7c82541a2e99f76af570d3faa897504149913a # good: [66a2c077694c47af9c40b46f740eab2d59f15efb] source-hash-c7d23291ea9ae7a3a2c055b09fce9c29bb7f58d3 git bisect good 66a2c077694c47af9c40b46f740eab2d59f15efb # bad: [433c1b577d7fb6f2823f2744f58928315fffda7f] source-hash-b08f87b62db81b498ea71e5e1049b96e3dc42da4 git bisect bad 433c1b577d7fb6f2823f2744f58928315fffda7f # skip: [8aa3a374f3a48f3292974bf2ad56acdece17681e] source-hash-47287df1cbb0745596bf0ba81e0371189ac35afd git bisect skip 8aa3a374f3a48f3292974bf2ad56acdece17681e # bad: [9e8ed0ba2ec0088da449dbb3a97b1eac48f64352] source-hash-274f497b2502db146f23eb72426ad38a70934540 git bisect bad 9e8ed0ba2ec0088da449dbb3a97b1eac48f64352 # bad: [6e63c0a2de7f596f543aff91720ec24c98e69d4e] source-hash-15d2655fb68254f39c59b97a7ca7713d12b0f1fa git bisect bad 6e63c0a2de7f596f543aff91720ec24c98e69d4e # bad: [d5e45cf761cd10fffa52a12ba64e3f0139dad408] source-hash-032517ba36c328a4df36cd9f2ea54ad13c316721 git bisect bad d5e45cf761cd10fffa52a12ba64e3f0139dad408 # good: [5f0c4ed59492110f1bf70252af3bd7d570a53305] source-hash-057fb145f13a85095fd296731a17ba95483d4434 git bisect good 5f0c4ed59492110f1bf70252af3bd7d570a53305 # bad: [34b5f862f46930f8c5cce2a908a165db39bbc8dd] source-hash-5333782d090a9e147c0c431f0f741863d1d8cf8e git bisect bad 34b5f862f46930f8c5cce2a908a165db39bbc8dd # good: [6095d9a2dd82a73733ac6afebf10d12e379e5c9a] source-hash-723b6a07e4c4dfb8fdafc186041557514b014014 git bisect good 6095d9a2dd82a73733ac6afebf10d12e379e5c9a # good: [a02aaf3b55d4b0b3e46b12e4fd8b5d827352f80c] source-hash-4b8f1dc1c8635c412b4669101e8871fa0cf26ff9 git bisect good a02aaf3b55d4b0b3e46b12e4fd8b5d827352f80c # good: [b48744e7d8edf6e6067d8599b5ce98ce1bebe7ec] source-hash-a5b5ad9f9306d868430ed9efd210b95c24a15161 git bisect good b48744e7d8edf6e6067d8599b5ce98ce1bebe7ec # first bad commit: [34b5f862f46930f8c5cce2a908a165db39bbc8dd] source-hash-5333782d090a9e147c0c431f0f741863d1d8cf8e
@Noel: Could you possibly have a look at this? As far as I understand it right now, there might be another, but more or less similar problem that exists since commit 031a347668e56c1b38c0539d30e9a1cbb808ca02, as described in comment 13. Just my personal opinion: To avoid side-effects of this, it might be helpful to first build with SAL_USE_VCLPLUGIN=gtk (as described in comment 11) and make sure it works again then. After that, it might be necessary to build without that option to see whether it still works or whether the gtk3 part has to be looked at separately.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dfc81188d50472dde2aa50752b415feab12350b4 tdf#92788 - Middle Button on Mouse Paste Option Broken for X11 It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Request please this be patched in 5.0 too, for 5.0.1 release. We have a lot of users that paste in this manner.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b556192d5cf43a2505755d98c96d48bf841e9da&h=libreoffice-5-0 tdf#92788 - Middle Button on Mouse Paste Option Broken for X11 It will be available in 5.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Michael Weghorn from comment #15) > @Noel: Could you possibly have a look at this? > > As far as I understand it right now, there might be another, but more or > less similar problem that exists since commit > 031a347668e56c1b38c0539d30e9a1cbb808ca02, as described in comment 13. > > Just my personal opinion: To avoid side-effects of this, it might be helpful > to first build with SAL_USE_VCLPLUGIN=gtk (as described in comment 11) and > make sure it works again then. After that, it might be necessary to build > without that option to see whether it still works or whether the gtk3 part > has to be looked at separately. The gtk3 issue is still present, I have opened a separate bug report for this: bug 93198
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
I still see the issue with the KDE version of libreoffice Version: 5.4.0.3 Build ID: 92c2794a7c181ba4c1c5053618179937228ed1fb CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4;
(In reply to sergio.callegari from comment #21) > I still see the issue with the KDE version of libreoffice > > Version: 5.4.0.3 > Build ID: 92c2794a7c181ba4c1c5053618179937228ed1fb > CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; Me as well for .deb install and flatpak install Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: kde4;
See bug 110988, fix will come in 5.4.1.