When I updated my system (Sparky Linux 4. Code Name: Tyche, based on Debian 9 Stretch Testing) on Friday 25th July 2016, and then used my upgraded Libreoffice, I found that when I scroll a large odt document of say fifty or more pages, I find lines of text disappear or only fractionally appear. Also, when I do word searches, I find sections of text getting jumbled as the scrolling often can't keep up with it. I never had this trouble with the previous version 5.1.4~rc1-1 and when I booted into my secondary OS, namely Debian Stable Jessie, using the old 4.3.3-2+deb8u5, I had no problems and was able to do my work.
Could you test version 5.2: https://wiki.documentfoundation.org/Installing_in_parallel/Linux Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835662. This was with 5.2.0. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835662#17 (unfortunately he didn't Cc his reply to the bug so it's not recorded, but the quote should be clear.)
Reporter sent this private mail: Just over a week ago, I replaced my Sparky Linux based on Debian Testing Stretch with pure Debian Testing Stretch. It had Libreoffice 5.2, and it initially worked fine. However, a few days later after installing and uninstalling software to get my system the way I wanted, suddenly, the same problem with Libreoffice writer returned. I ended up submitting a bug report to Debian just last Sunday, and on that same day, someone from the Debian team suggested to me the problem may be related to libreoffice-gtk2/libreoffice-gtk3, and to execute the command dpkg -l libreoffice-gtk2 libreoffice-gtk3 When I did,I got the following output: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===========================-==================-==================-============================================================ ii libreoffice-gtk2 1:5.2.0-2 amd64 office productivity suite -- GTK+ 2 integration rc libreoffice-gtk3 1:5.2.0-2 amd64 office productivity suite -- GTK+ 3 integration What is critical here, is that while I was installing/uninstalling software, I must have unwittingly uninstalled libreoffice-gtk3 while I think I was uninstalling the buggy Mate desktop which had been giving me grief. My main desktop is Xfce. When I reinstalled libreoffice-gtk3, the problem disappeared. Now when I scroll or do searches on a large document, libreoffice writer works fine. As well, the Mate desktop, having switched to gtk3, seems to me, much less stable. Another thing. This problem only became apparent on sizeable documents like 50 pages or more. For say just eight pages, there was no problem. Hence, this is a bug that for most people would be hard to detect. However, I work on documents over 500 pages, so for me, this bug made libreoffice writer almost unusable.
Vince: maybe you could do some tests without touching the libreoffice-gtk3 package. See, if you can reproduce the problem by running libreoffice from the terminal with the command: SAL_USE_VCLPLUGIN=gtk libreoffice If you get slow scrolling with that environment variable, you could next try this bit of sorcery: SAL_USE_VCLPLUGIN=gtk SAL_SYNCHRONIZE=1 libreoffice The results of these experiments might be useful information for developers.
Reporter again emailed me privately: I just did the two quick experiments. The first, SAL_USE_VCLPLUGIN=gtk libreoffice still produced the bug. However, doing the sync with SAL_USE_VCLPLUGIN=gtk SAL_SYNCHRONIZE=1 libreoffice eliminated the bug. (end of quote) Caolán just posted an explanation of what the synchronize variable does: https://bugs.documentfoundation.org/show_bug.cgi?id=100925#c33
Reporter emailed me again: Presently I am using libreoffice 5.2.1-1 on Debian Testing. Recently I was noticing very slow or sluggish performance even when opening small documents. Small spreadsheets were taking about 10 seconds or more to open for example. I googled this problem and found I was not alone. However, when I executed the magical: SAL_USE_VCLPLUGIN=gtk SAL_SYNCHRONIZE=1 libreoffice the sluggish performance is gone! --- Because I think,it is not using the bug riddled gtk3.
I have the same problem with LibreOffice 5.3.0.3 in Arch Linux. Using: SAL_USE_VCLPLUGIN=gtk SAL_SYNCHRONIZE=1 libreoffice helps with scrolling issues.
NEW per previous comment. Severity minor as workaround exists.
Some additional observations: - This issue does not happen with the mouse wheel, only with the touchpad of my Dell XPS 13 - Horizontal scrolling is way too fast, even with the workaround above. With one little swipe, I'm already at columns AE-AR Running a Gnome Wayland session (with gdm login manager).
(In reply to matthieupepin from comment #9) > - This issue does not happen with the mouse wheel, only with the touchpad of > my Dell XPS 13 Other touchpad scroll issues: https://bugs.documentfoundation.org/buglist.cgi?list_id=682144&query_format=advanced&resolution=---&short_desc=touchpad%20scroll&short_desc_type=allwordssubstr
I'm running LO 5.2.1.2 on Archlinux (from the Arch Repos), and in my opinion the bug is GTK3 related. running SAL_USE_VCLPLUGIN=gtk libreoffice eliminates the bug for me, without even using SAL_SYNCHRONIZE=1. If I run libreoffice with GTK3 the problem reappears, even if i run it using SAL_SYNCHRONIZE=1.
I updated today from Lubuntu 16.10 (LO 5.2. or 5.3.0) to 17.04 beta and have now LO 5.3.1.2. (LO-Build-ID: 1:5.3.1-0ubuntu2) - and I have now the same problem with scrolling even small odts via touchpad on my compaq presario CQ61. SAL_USE_VCLPLUGIN=gtk libreoffice and SAL_USE_VCLPLUGIN=gtk SAL_SYNCHRONIZE=1 libreoffice both do help quite a bit, but I have the impression, scrolling with previous versions of LO (and/or gtk?) were much smoother.
Addition to my previous comment: uninstalling libreoffice-gtk3 also helps.
Same issue (rough scrolling) under Win10, LibreOffice v5.3.4.2 (x64). In particular, scrolling around the autogenerated Index takes more time for the page to refresh. Text search seems to work fine.
(In reply to dr01 from comment #14) > Same issue (rough scrolling) under Win10, LibreOffice v5.3.4.2 (x64). In > particular, scrolling around the autogenerated Index takes more time for the > page to refresh. Text search seems to work fine. Your issue is likely bug 113347, let's set this to Linux only again.
Dear vince.barwinski@gmail.com, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug has not been an issue for me for two years now. I just tested a document with over 495,000 words with the gtk3 integration (the bug was only an issue with the gtk3 integration). The good news is, the document scrolled perfectly. All the best
And I used the latest libreoffice 6.3.2 in Debian Testing (Bullseye).