Version: unknown (using KDE 3.1.9) Compiler: gcc version 3.3 20030226 (prerelease) (SuSE Linux) OS: Linux (i686) release 2.4.20-4GB-athlon I found this bug (http://bugs.kde.org/show_bug.cgi?id=45180), but it was marked as resolved, and had not been active for some time it seemed. The current (cvs) way scrolling in konq is taken over by dropdowns, text areas, etc is not usable. Scrolling down a page to then interrupted by changing options of a dropdown is very bad. This has been reported before (as mentioned by the bug report), and was wondering the status of if this was being worked on, and if so, what was going to be the outcome.
This happens in KDE 3.1.1 also, but only when a form control is selected. When scrolling the page and the mouse pointer touches a selected control, this control steals the scroll-events from the web-page. This is very annoying indeed. Solution (= the way I would like it to work): - Form-controls should never receive scrolling events by default - When the user selects a control, this control should receive scrolling events. - When the user deselects the control, the control should stop receiving scroll events. Dik
I agree, that is the way I feel it should behave as well.
Comment #1 describes the behaviour in my system (HEAD built on 20030524). If the current HEAD has the same problem as before, it's a bug that has resurfaced will be corrected. It's not the intended behaviour. For instance, scrolling in this page right now with the mouse wheel, the page goes up and down even if the mouse pointer passes over this text area IF the text area is not selectioned. If it is, it'll receive wheeling events when the pointer is over it. The same goes for drop-down boxes: they don't get any events unless I clicked on it first and only then if the pointer is over the widget. The only widget that gets scrolling events in spite of being selected or not is the scrollbar. If the mouse pointer lands over it during wheeling, the next event will scroll the textarea associated.
I have HEAD built on 20030702 (last night) and both drop down boxes as well as text areas recieve wheeling events without scrolling. I have tested this on hotmail (while writing a new message, if i scroll down the middle, the To: or From: or Subject: (etc) lines will be selected just by scrolling, as well as the text area for the message itself. Buttons for send, save draft, etc will also react as if they were selected, but not depressed (no action is made, but the retanage box like I had tabbed to them is brought up). While playing around with it more before I added this, I have noticed this to be somewhat sparatic. Right now as I scrolling over the To: From: etc fields, they do become selected (to be able to type) as I just scroll over them, but the page continues to move up or down. The message type area though does not, as once it is scrolled within, it takes over. Also, the scroll boxes on deviantart.com scroll without selection.
I can confirm the problem, even though I don't see it a big problem (the combo boxes were much more evil :)
*** This bug has been marked as a duplicate of 45180 ***