It should be possible to scroll inside of a document by simply hovering the mouse cursor on top of a window, without having to select it as active window first by clicking it. This does work with any GTK 3 UI in a KDE Plasma 5.14 Xorg session, but not with LibreOffice and its gtk3_kde5 and gtk3 VCLs. When hovering the cursor on top of the LO window, no scrolling happens when using mousewheel scrolling. However, there is one odd detail: When hovering the mouse cursor exactly on top of the scroll bar and then doing mousewheel scrolling, the scrollbar briefly flashes (without scrolling, though). So there apparently is some input send to the LO window, but it seems it doesn't get handled correctly. In a Gnome Xorg session, scrolling inside of documents works without having to activate the window by clicking it. But: Again there is the weird behavior when moving the cursor exactly onto the scrollbar. When the window isn't activated, the scrollbar just flashes instead of scrolling, like in the KDE Plasma session. This does not happen with any other GTK application. So, to sum up: Mouse wheel scrolling should work also for inactive windows, no matter if KDE Plasma or Gnome session. And it also shouldn't matter if the mouse cursor is placed directly onto the scrollbar or not. I btw. originally reported this bug to KDE, their opinion is that it needs to be fixed in LO: https://bugs.kde.org/show_bug.cgi?id=399138
Works for me in master on KDE5 (Debian buster local, via remove SSH in a patched Ubuntu 18.04 chroot with KF 5.44) for gen, kde4, qt5 (+ kde5), gtk(2) but *not* gtk3 (+ gtk3_kde5), so I guess it's a gtk3 specific problem. gtk3_kde5 just adds a KF5 filepicker but otherwise is the same code as gtk3. Now I don't know why it works in Gnome Xorg, so there might be something desktop-specific involved. Just a general note: always check About -> LibreOffice for the used VCL plugin when reporting. That info there is selectable text so easy to copy and has some additional information, which might help debugging. LO has fallbacks for missing VCL plugins, depending on the detected desktops, but About -> LibreOffice tells which VCL plugin is actually in use. That code is even used if you override the default detection via SAL_USE_VCLPLUGIN, so a missing default would still allow LO to start. I had commented the kde5 plugin in my build, but not qt5, and LO showed the broken gtk3 behavior for kde5, which puzzled me at first... turned out it used gtk3_kde5 until I enabled the kde5 VCL for the build :-)
(In reply to Jan-Marek Glogowski from comment #1) > Works for me in master on KDE5 (Debian buster local, via remove SSH in a > patched Ubuntu 18.04 chroot with KF 5.44) for gen, kde4, qt5 (+ kde5), > gtk(2) but *not* gtk3 (+ gtk3_kde5), so I guess it's a gtk3 specific > problem. gtk3_kde5 just adds a KF5 filepicker but otherwise is the same code > as gtk3. Same for me on Debian buster and a local build, i.e. no SSH/chroot indirection (only kde5, gen, gtk2 and gtk3 tested).
it works fine for me in Versió: 6.1.3.2 ID de la construcció: 1:6.1.3~rc2-0ubuntu0.16.04.1 Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3; Configuració local: ca-ES (ca_ES.UTF-8); Calc: group threaded
*** This bug has been marked as a duplicate of bug 119976 ***