Description: Arranging multiple Windows next to each other is a common use case. However LibreOffice doesn't allow to scroll while it doesn't have focus. Thus it's required to first click into the LibreOffice window to make it active before scrolling is possible. Allowing scrolling while the window is inactive would improve usability for those use case greatly. Steps to Reproduce: - Open LibreOffice and some other application (e.g. Firefox) next to each other. - Make the Window of the other application active by clicking in it - Put the mouse over the LibreOffice Window and turn the mouse wheel. Actual Results: LibreOffice doesn't scroll Expected Results: LibreOffice should scroll Reproducible: Always User Profile Reset: No Additional Info:
It works for me with LO 6.1.1 under Ubuntu 18.04 x86-64 with Gnome-shell and the GTK3 backend. What is your window manager? My version: Version: 6.1.1.2 Build ID: 1:6.1.1~rc2-0ubuntu0.18.04.1~lo3 Threads CPU : 4; OS : Linux 4.15; UI Render : par défaut; VCL: gtk3; Locale : fr-FR (fr_FR.UTF-8); Calc: threaded Status set to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided. Best regards. JBF
I'm using KDE Plasma 5.13 under Arch Linux. I haven't enabled any backend explicitly. The About-Dialog of my LO shows the following information: Version: 6.1.1.2 Build-ID: 6.1.1-2 CPU-Threads: 4; BS: Linux 4.18; UI-Render: Standard; VCL: gtk3_kde5; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group threaded
Created attachment 145091 [details] it works on 6.2 linux - see video For me it works under linux. LO 6.2. See the video Version: 6.2.0.0.alpha0+ Build ID: 66232248ff55639052ddb76918d555e21dc9c46b CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-09-20_19:40:04 Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
In Windows this also seems to depend on the application in front, which might not let the event get to the unfocused LibreOffice window.
It does not work with gtk3 and gtk3_kde5. Works with gen and gtk2. It works on Windows. It works for JBF under Gnome shell, so probably this is related to KDE. It is not normal for KDE applications, however.
I can't reproduce it in Version: 6.2.0.0.alpha1+ Build ID: cd6dd8c6f3562cbccbc971b916c6a8933840ffeb CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
In Kubuntu, I can reproduce it in Version: 6.2.0.0.alpha0+ Build ID: 3846561f79cf9065abd9ca83c9fbfbe7e52e28e2 CPU threads: 1; OS: Linux 4.13; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-10-21_02:45:54 Locale: en-US (en_US.UTF-8); Calc: threaded and in Version: 6.2.0.0.alpha0+ Build ID: 3846561f79cf9065abd9ca83c9fbfbe7e52e28e2 CPU threads: 1; OS: Linux 4.13; UI render: default; VCL: kde5; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-10-21_02:45:54 Locale: en-US (en_US.UTF-8); Calc: threaded it has a strange behaviour, it scrolls a bit but not reaching the bottom of the document. Not reproducible if using gtk or kde4
(In reply to Xisco Faulí from comment #7) > it has a strange behaviour, it scrolls a bit but not reaching the bottom of > the document. > I have the same result for ALT Linux KDE Plasma 5.12.7, KDE frameworks 5.49.0, QT 5.9.6 Version: 6.2.0.0.alpha1 Build ID: ff46ad24d1d3cbcea45895520483ed1fd4ff488b CPU threads: 1; OS: Linux 4.14; UI render: default; VCL: kde5; Locale: ru-RU (ru_RU.UTF-8); Calc: threaded
Actually I was about to file a bug for a similar issue in the Libo tracker, after filing this KDE bug : https://bugs.kde.org/show_bug.cgi?id=401225 What I noticed is, when opening Libo on a 2nd virtual desktop, and switching back and forth, mouse focus was lost, but not keyboard focus. To be more accurate, mouse focus is not really lost, but when using the mouse-wheel, it doesn't scroll the page but has an effect on *toolbars* instead. A KWin developer thinks this is an upstream (Libo) bug. I quote Martin F. : "KWin is not responsible for mouse event handling on X11." Could someone help pin-point this mouse-focus issue under KWin ? Cheers !
(BTW my setup is : KDE Neon, Xorg, latest KDE stack, latest Libo from the Fresh PPA).
I'd like to add that sometimes, even clicking inside the Libo window doesn't make the mouse-wheel events work again although Libo clearlt has the keyboard focus. I sometimes have to reduce & raise Libo to get the mouse-wheel scrolling work again.
*** Bug 120584 has been marked as a duplicate of this bug. ***
I found a workaround in the Arch Wiki for KDE Plasma by setting GDK_CORE_DEVICE_EVENTS=1 It however mentions that this breaks touchpad smooth scrolling and touchscreen scrolling.
I am using writer shipped with version 6.1.5.2 and the scrolling functionality using the mouse wheel is enabled i.e. it works most of the time. But I can reproduce a problem, it happens that the window doesn't react to the rotation of the wheel in the following way: * Give focus to another application * Go with the mouse over the writer window but don't click inside it to give focus * Try to scroll with the mouse The writer window gets the focus from the window manager but the scrolling doesn't work. To have it again working it's sufficient to give the focus to another application and return to writer window clicking inside it. After that you can use the wheel to scroll the document. In the past I didn't have this problem, probably it appeared in the transition between libreoffice 5 and 6. I am using an old KDE3 desktop environment, libreoffice is compiled with --enable-gtk3-kde5, --enable-gtk and --enable-gtk3
(In reply to tempel.julian from comment #13) > I found a workaround in the Arch Wiki for KDE Plasma by setting > GDK_CORE_DEVICE_EVENTS=1 > It however mentions that this breaks touchpad smooth scrolling and > touchscreen scrolling. in my case the workaround doesn't seem to work if I execute writer with $ export GDK_CORE_DEVICE_EVENTS=1 $ lowriter Other apps using GTK3 like firefox doesn't have this problem, even without setting the GDK_CORE_DEVICE_EVENTS variable
(In reply to Vera Blagoveschenskaya from comment #8) > (In reply to Xisco Faulí from comment #7) > > > it has a strange behaviour, it scrolls a bit but not reaching the bottom of > > the document. > > > > I have the same result for ALT Linux > KDE Plasma 5.12.7, KDE frameworks 5.49.0, QT 5.9.6 > > Version: 6.2.0.0.alpha1 > Build ID: ff46ad24d1d3cbcea45895520483ed1fd4ff488b > CPU threads: 1; OS: Linux 4.14; UI render: default; VCL: kde5; > Locale: ru-RU (ru_RU.UTF-8); Calc: threaded Can you retest with current master? I can't reproduce here it here. This was probably fixed for kde5 when I fixed bug 125201. If it's fixed for kde5, remove the KDE block, as gtk3_kde5 just uses the KDE5 file picker and is otherwise gtk3 code.
Still reproducible with Version: 6.4.0.0.alpha0+ Build ID: 77a3c443d35c7d966217f02ea9189cb1819c7828 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded on Debian testing with Plasma desktop on X11 (plasma-desktop 4:5.14.5.1-1).
(In reply to Jan-Marek Glogowski from comment #16) > Can you retest with current master? > I can't reproduce here it here. > > This was probably fixed for kde5 when I fixed bug 125201. If it's fixed for > kde5, remove the KDE block, as gtk3_kde5 just uses the KDE5 file picker and > is otherwise gtk3 code. Mouse wheel scrolling without focus works for me in KDE Neon (Ubuntu 18.04-based) with LibreOffice 6.2.5.2 and kde5-VCL: Version: 6.2.5.2 Build-ID: 1:6.2.5-0ubuntu0.18.04.1~lo1 CPU-Threads: 8; BS: Linux 4.18; UI-Render: GL; VCL: kde5; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded
(In reply to Gunter Ohrner from comment #18) > (In reply to Jan-Marek Glogowski from comment #16) > > Can you retest with current master? > > I can't reproduce here it here. > > > > This was probably fixed for kde5 when I fixed bug 125201. If it's fixed for > > kde5, remove the KDE block, as gtk3_kde5 just uses the KDE5 file picker and > > is otherwise gtk3 code. > > Mouse wheel scrolling without focus works for me in KDE Neon (Ubuntu > 18.04-based) with LibreOffice 6.2.5.2 and kde5-VCL: > > Version: 6.2.5.2 > Build-ID: 1:6.2.5-0ubuntu0.18.04.1~lo1 > CPU-Threads: 8; BS: Linux 4.18; UI-Render: GL; VCL: kde5; > Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE > Calc: threaded here 6.2.5.2 built from sources as indicated in comment #14 still doesn't work on my system: Version: 6.2.5.2 Build ID: Gentoo official package CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: it-IT (it_IT.UTF-8); UI-Language: en-US Calc: threaded
For clarification: This happens when the gtk3 or gtk3_kde5 VCL plugins are used on KDE Plasma. It doesn't happen * with the kf5 VCL plugin (previously called "kde5") on Plasma * with gtk3 VCL plugin on GNOME
I am having the same problem. Mageia Linux 7.1, libreoffice-core-6.2.3.2-3.mga7, plasma-desktop-5.15.4-1.mga7 Firefox will scroll without focus, LibreOffice will not scroll without focus. It is very annoying.
(In reply to crxssi from comment #21) > I am having the same problem. Mageia Linux 7.1, > libreoffice-core-6.2.3.2-3.mga7, plasma-desktop-5.15.4-1.mga7 > > Firefox will scroll without focus, LibreOffice will not scroll without > focus. It is very annoying. As mentioned above, you shouldn't experience this issue if you're using the so-called "kde5" ("kf5" from upcoming 6.4 release on) VCL plugin instead of the "gtk3" one. I don't know whether Mageia ships this one, but if you're using the TDF-provided packages, this is included in the kde integration package and will be used by default if installed.
I am having the same annoying problem with LibreOffice not allowing unfocused wheel scrolling. I didn't realize how often I used it, until it was broken. Only LO is broken, other programs work fine (Firefox, Pidgin, Konsole, Claws, Pluma, etc, etc). In my case: Mageia 7 LibreOffice 6.2.8.2 (mga) KDE Plasma 5.15.4 (mga) I do have both libreoffice-kf5 and libreoffice-gtk3 installed, makes no difference. If I use "export GDK_CORE_DEVICE_EVENTS=1" before launching LO, it fixes the problem. I did install gedit, and noticed that gedit exhibits the same behavior as LO- it will not scroll without focus, unless I set GDK_CORE_DEVICE_EVENTS=1. So I don't think this is specifically about LO.
(In reply to crxssi from comment #23) > > I did install gedit, and noticed that gedit exhibits the same behavior as > LO- it will not scroll without focus, unless I set GDK_CORE_DEVICE_EVENTS=1. > So I don't think this is specifically about LO. Considering this could we close this bug as Not our bug?... it's a KDE bug.
Dear Manuel Vögele, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug no longer happens for me. Version: 7.4.6.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE 7.4.6-1 Calc: threaded