For example run Writer and move mouse cursor to Toolbar on Font Size or Font Family combobox. No click to combobox, only turn mouse wheel and the page will be scrolled instead the values in combobox. Bug: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 8f058de233e5110720daa5b42e0c66e7c3b2c31f CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: en-US Calc: CL Ok in: Version: 7.4.0.3 (x64) / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 8; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL
I confirm with Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 641d92a73e5b3d0e062e16ed4b42236e1a4796a5 CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: threaded Not repro with Version: 7.4.1.0.0+ / LibreOffice Community Build ID: 68e173760d6cc5dd80384b231428d8d9a658d4b9 CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: threaded
Interesting, the scrolling of unfocused dropdownboxes was possible in: Version: 6.4.7.2 Build ID: 1:6.4.7-0ubuntu0.20.04.4 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded But not in Version: 7.1.8.1 / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded or any later version I tested (7.4.0.3, 7.5 alpha), at least for me with Ubuntu 20.04 and GTK3. Might have to do with 6.4 being installed from repo and others from .deb. Can you still scroll in the sidebar, for example in the gallery deck?
This seems to have begun at the below commit. Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks 8920c1f1a24d11b90912f8a4faa510243624802e is the first bad commit commit 8920c1f1a24d11b90912f8a4faa510243624802e Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Apr 21 12:23:29 2020 +0200 source 2e0a32b51681fb356699b4a722f461f55a46b890 https://git.libreoffice.org/core/+/2e0a32b51681fb356699b4a722f461f55a46b890
Isn't this really a consequence of bug 149823 where I was asked to explicitly make the mouse wheel only change values of a combobox/spinbutton if has focus.
Yes, it seems it is the consequence of bug 149823. My opinion is the scrolling with autofocus was better. It is redundance to click to combobox etc. for scrolling, thereto there is an unexpected behavior you scrolled in the place outside of page and the page is scrolling. I think the easier is to remember the elements have the autofocus than remove the autofocus and make the manipulation a little bit complicated (with extra click) and with unexpected behavior -> you see anyway where you have the mouse cursor, so if you know there is autofocus, you can move the cursor out of changeable element, there is mostly some place - or you can always move the cursor to scrollbar and scroll there :-). If you change the properties in comboboxes etc. many times, then the autofocus is really pleasant facilitation.
Just to add some more context, it looks like it stopped being possible scrolling these unfocused elements in the 7.0 branch, for GTK3 on Linux. However, for VCL plugins Gen and KF5, I can confirm that it started not being possible to scroll them in 7.5. So, if anything, this change makes it more consistent with what was already the case with GTK3.
at the end of the day I think its ok as it is now and not worth changing further