When opening a CSV file in libreoffice calc, in the CSV import dialog, the file encoding UI element is focused automatically. It’s not possible to unfocus it without changing focus to another UI element. This has the side-effect that errant scroll events when the cursor is anywhere within the import dialog (which can happen very easily when using a trackpad) change the encoding, and require opening the dialog, finding whatever was selected before, re-selecting it, then quickly focusing another UI element to avoid the problem recurring. It would be nice if this didn’t occur. Personally I would only expect scroll events to be handled by these dropdowns either when one is open or my cursor is hovered directly over it. Having scroll events elsewhere on screen handled by an inactive dropdown which happens to be focused by default is unexpected and unwelcome behaviour. Version information: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 20; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Ubuntu package version: 4:7.6.2-0ubuntu1 Calc: threaded
Confirm that the Import dialog opens *with focus* onto the 'Character set' list box, and that it responds to mouse wheel scroll. Something on the dialog needs to have focus on opening, and keyboard <Tab> will advance to next control in the dialog. While mouse pointer selection of a control is equally functional. Not clear that is really an issue, and we need users to focus on the dialog's representation--adjusting the character set encoding in the listbox provides immediate feedback on how the file will be parsed. Keep finger off the Wheel scroll?
Thanks for the quick response! However, I suspect that the speed may have resulted from not having read my bug report properly. My comment clearly stated that the unexpected behaviour is the dropdown value being changed a) while it is focused (default state) but NOT ACTIVE (i.e. not open, the user has not interacted with it), and b) a scroll input is detected ANYWHERE IN THE DIALOG, not only while the dropdown element is active (i.e. the user has clicked on it) or hovered over I propose some simple user testing. Ask a user to open a CSV file, ask them to place their cursor over the dialog but NOT over any control, ask them to scroll and observe the result. Then ask them if the outcome (described in my issue) matches their expectation. > Keep finger off the Wheel scroll? Again, very clearly stated in my original comment, but now with emphasis added: “(which can happen very easily when USING A TRACKPAD)” It is admittedly a minor issue, but minor issues which result in annoying, unexpected behaviour like this quickly add up and result in dissatisfaction with the software.
OK, can understand issue when using a trackpad or trackball... @Eike, Kohei -- opinion? Should the CSV Text import dialog have a default control with focus on opening, or not? Appreciate that the first action for import is to verify the character set of the CSV source, and advancing through the dialog with <TAB> is the intended workflow.
I am not sure but I think that the initial focus on file encoding was set intentionally. There might be some report about it. I could be wrong. Even if there is such request somewhere, perhaps the logic might need some review anyway. FWIW, the character set is the first/upper field in the dialogue, so in that aspect, there is some logic.
To clarify, I don’t think there’s anything wrong with the character set dropdown being focused (but inactive) by default, or being the first item in the dialog. The unexpected behaviour is specifically that scroll events *outside* the focused-but-inactive UI element opens it and changes its value, despite me not having explicitly interacted with it. I realize this could just as well be an issue with the UI framework being used (I assume GTK?) which you have no control over, but this is the only place where I’ve consistently run into issues with it so thought I’d report it here in case it was straightforward to fix.
I think we should ping Heiko for this sort of UI issue (CC'ed). We may consider this issue partly as an issue with VCL esp. the part where the drop down receives input from the wheel even when the mouse cursor is outside the dialog. But to me it would be entirely reasonable to move the widgets around so that the one with the initial focus would be the one that the user changes more frequently, which I doubt is the character set. Having said that, my inclination is to ask Heiko.
(In reply to Kohei Yoshida from comment #6) > I think we should ping Heiko for this sort of UI issue (CC'ed). We may > consider this issue partly as an issue with VCL esp. the part where the drop > down receives input from the wheel even when the mouse cursor is outside the > dialog. Actually I tried it again now with my local build and my build doesn't do that (GTK3 on Linux, 7.3.7 and the master build). But I did see this behavior with the TDF Windows version earlier... Maybe it's a VCL issue.
(In reply to Kohei Yoshida from comment #6) > the one with the initial focus would be the one that the user changes more > frequently, which I doubt is the character set. Initial focus on the more frequent action can be useful, but OTOH it would also make easier for users to "jump" directly to the result instead of "thinking" about the options in the dialogue. This is also a frequent reason for users to obtain the "wrong" result, or not to notice that they are not using the adequate options for their case. Navigating through the options from top to bottom of the dialogue helps in this regards, especially when there are so many independent options and so many alternative results depending on them.
Windows changes the focus on scroll. And gtk3 does not scroll dropdown lists at all but when the "from row" spinedit is active it not only scrolls this control but also the column type list. The issue is not limited to the CSV dialog. KDE scrolls only if the cursor is over the control (settings > appearance > fonts > sub-pixel rendering, for example). Can we do the same? On all VCL.
Created attachment 191289 [details] Simple CSV file @Barnaby: What does your version information in "Help" -> "About LibreOffice" say? (In reply to Heiko Tietze from comment #9) > Windows changes the focus on scroll. (...) > > KDE scrolls only if the cursor is over the control (settings > appearance > > fonts > sub-pixel rendering, for example). Can we do the same? On all VCL. In my tests (using a mouse scroll wheel, Debian testing, KDE Plasma X11 session with KWin as window manager), kf5 and qt6 on Linux basically behave the same as Windows: 1) When the mouse pointer is above the previous area, that one is scrolled 2) When the mouse pointer is ~anywhere else above the LO dialog: the combobox entry changes on scroll (as described here) 3) When the mouse pointer is outside of the dialog area: Nothing happens in the LO dialog on scroll. > And gtk3 does not scroll dropdown lists > at all but when the "from row" spinedit is active it not only scrolls this > control but also the column type list. The issue is not limited to the CSV > dialog. With the simple CSV file I've used for testing (s. attachment), the "Column type" listbox is grayed out for me, so doesn't do anything. I can confirm that in a native Qt application (I tried Kate settings), the listbox value only changes when the mouse pointer is above the listbox. Likely, Qt-based LO VCL plugins (qt5, qt6, kf5, kf6) will behave likewise when support for native Qt controls (welding) gets implemented (tdf#130857), which an Outreachy intern is working on [1]). That still leaves the remaining implementations that use the VCL implementations (likely gen, Win, macOS). Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 185cd83bf58d8c834a9690cdd6a25736787abbf7 CPU threads: 12; OS: Linux 6.5; UI render: default; VCL: qt6 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: f461853b11439c4e485a79174d34735395e5bf52 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_DE); UI: en-US Calc: threaded [1] https://lists.freedesktop.org/archives/libreoffice/2023-December/091281.html
(In reply to Michael Weghorn from comment #10) > Created attachment 191289 [details] > Simple CSV file > > @Barnaby: What does your version information in "Help" -> "About > LibreOffice" say? Oh, it's in your initial comment already, I was just confused because you mentioned Gtk later: Version information: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 20; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Ubuntu package version: 4:7.6.2-0ubuntu1 Calc: threaded
So, if you want to avoid this from happening for now, an option would to be to switch to the gtk3 VCL (UI variant) instead of the kf5 one, by setting environment variable SAL_USE_VCLPLUGIN=gtk3 before starting LibreOffice.
(In reply to Heiko Tietze from comment #9) > KDE scrolls only if the cursor is over the control (settings > appearance > > fonts > sub-pixel rendering, for example). Can we do the same? On all VCL. https://gerrit.libreoffice.org/c/core/+/160459 is a suggested implementation for the VCL ListBox, i.e. all VCLs not using native widgets. Native widgets IMHO shouldn't be changed, but adhere to whatever the toolkit does.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/22250df05830700b2555348b8ac46ee1007d0e5d tdf#158548 vcl: Require mouse over listbox to mouse-wheel through entries It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/b0b5ae68cbc95990ad72653212005ef89d7f3ea3 tdf#158548 vcl: Require mouse over listbox to mouse-wheel through entries It will be available in 24.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Wow, that was quick! Thanks a lot for this fix, looking forward to it landing in 24.2