When the mouse hovers over a slider, spinbox, or dropdown menu, scrolling will adjust its value rather than scroll the window content. How can I change this behaviour?
It often happened to me that I changed settings unintentionally, this is very annoying.
I am using KDE Neon, btw
2 Likes
i think just depends on the focus of where the cursor is pointed… i don’t know of a way to have the scroll wheel work when focused on somethings and not work when focused on other things.
you just need to pointed at the page or the slider before you scroll if you only want to move the page.
This is very annoying, in fact. Is there not any way to brute force disable this?
Something like the dconf Editor of GNOME??
1 Like
Here’s a quick example of where this turns into a stumbling block for me in the System Tray Settings Entries area. I’m a bit of a noob to Linux on the desktop, so if this is just how things are I can probably live with it, but given how so much is configurable in KDE, this would definitely be a nice UI/UX improvement at least for me. 
1 Like
this is just how combo boxes work… they work the same way in windows…they work the same on web pages.
that said, this is KDE and we specialize in control of your UX, so i would propose yet another obscure setting (of course).
2 Likes
Apologies for the ignorance here. 
I’m coming from a web development background and from Windows (as a desktop user, at least). So, my experience has been at least in Chrome, Firefox and etc this isn’t standard practice. That said, check out this test page: codepen[dot]io/patricknelson/pen/vEKGBpB
It looks like in Chrome, Firefox and Konqueror (couldn’t help myself), the dropdowns displayed there don’t look like the native combo boxes in this Entries list. So that may at least explain why it isn’t functioning consistently with the web-standard approach.
p.s. sorry, this system won’t allow me to paste links.
the last windows i used was win7 and it was definitely a thing there.
it was not hard to find a demo webpage where the combo box changes if you scroll the mouse wheel while on hover… you just have to make sure you are not hovering over the box
but with the additional settings option i posted above, it could make the combo box “dumb” and require a click inside the box to give it focus before scrolling the options
1 Like
Right, but that’s because it looks like it was just explicitly implemented that way. I was merely pointing out web standard behavior, that’s all. I totally understand the preference either way, though.
but with the additional settings option i posted above, it could make the combo box “dumb” and require a click inside the box to give it focus before scrolling the options
FWIW, there is no web specific standard as far as I’m aware where scrolling would affect the selection in the dropdown. I only call that out since that’s also something I prefer (i.e. scroll to not affect it at all). So, if a preference were provided, an ideal one for me subjectively would be that scrolling over a dropdown has no effect at all, regardless of focus.
so you would never want to be able to use the scroll wheel inside a combo box?
that is rather niche.
so you would never want to be able to use the scroll wheel inside a combo box?
lol, yes that is correct. But only prior to opening it. Once opened, the list pop up should be scrollable (but that’s unrelated to this).
Again, that’s my preference. Remember, above I said I was relatively new to Linux on the desktop (used it for 15yrs or so on the server). This sort of behavior I have never seen noticed* this before elsewhere, so it’s just a minor preference that has arisen from 20yrs of habit.
the last windows i used was win7 and it was definitely a thing there.
Double checking, I do see it now as well for native dropdowns (non-editable) and combo boxes (editable with text fields). So, it looks like I was wrong there!
On the original topic: Where dropdowns are used inside of scrollable content. Obviously, this still leads to an ambiguous UI/UX due to nesting. Also, on the web, it may very well be coincidental that this scrolling behavior didn’t take hold early on. I know as a webdev myself this will likely always be the case moving forward since capturing page scrolling is typically considered an antipattern (e.g. say you move past a Google Maps embed), so it seems unlikely that they’d adopt this into <select> fields.
I’m not sure there’s actually a good solution to this aside from A.) As a developer maybe avoiding nesting dropdowns in scrollable content where practical, and B.) As a user learning that you should avoid a column of dropdowns when scrolling through content! And I think the “Entries” area I used in my example above is probably best as-is using dropdowns, since it maximizes space available and also allows for a large number of options. 
moving this to Brainstorm since there is no way to change this behavior currently.