Bug 45180

Jesper is completely correct -- this is a severe usability issue. 

*** Bug 43944 has been marked as a duplicate of this bug. ***

*** Bug 41276 has been marked as a duplicate of this bug. ***

*** Bug 38513 has been marked as a duplicate of this bug. ***

*** Bug 22204 has been marked as a duplicate of this bug. ***

My idea would be to start a timer once scrolling starts and to don't activate 
combo boxes and text field scrolling before it runs out. 

*** Bug 45400 has been marked as a duplicate of this bug. ***

Subject: kdelibs/khtml/rendering

CVS commit by mueller: 

only allow wheel events to be send to embedded widgets if they have the
focus. 
CCMAIL: 45180-done@bugs.kde.org

  M  +2 -1     render_frames.cpp   1.143
  M  +7 -6     render_replaced.cpp   1.103

I just added the following to bug 41275 which is a duplicate of this bug (but 
not marked as such... can someone please do that): 
 
This has been bothering me as well, and I just came by to submit this  
"wishlist" item. Why don't you just inhibit the mouse scroll target from  
shifting while scrolling... I realize this isn't as simple as:  
 
if(last scroll event was less than 1 second ago) {  
don't change scrolling target  
}  
 
but, that behavior SHOULD be present. If the user scrolls that quickly, it  
should be aparent that they want to scroll the page and not the select box.  
Another way could be to only change the focus of the scroll to the select box  
if the mouse moves over the combo box (rather than the combo box moving under  
the mouse) 

*** Bug 41275 has been marked as a duplicate of this bug. ***

I see that in recent cvs, wheel scrolling of select boxes is disabled entirely unless the select 
box is "opened".  Is there a plan to go back to the "mouse over" operation that was in there 
before but with a delay timer or other mechanism in place (see my previous message) to allow 
the best of both worlds? 

I totally agree with jeremyhu@uclink4.berkeley.edu. The possibility of quickly 
choosing an option from a combo box WITHOUT clicking or focusing it in another 
is really useful, especially when filling large forms, like surveys etc. Sure, 
one has to be careful not to change an option when just scrolling around. I 
think it would be optimal to implement this "scroll timer" feature, so that 
both uncatious scrolling-through and unfocused combo-box selection would be 
possible. 
And I think that timer should be system-wide setting configurable in kcm-mouse 
(both the timeout and a possibility to disable the feature whatsoever, if one 
would like to, although by default it should be enabled), so that all the apps 
could benefit from it. 

Dirk says the bug reappeared due to Qt 3.2

*** Bug 60570 has been marked as a duplicate of this bug. ***

we could still release 3.2 with it, even though it sucks

I fully agree with the comments made there. I was just about to submit a bug for that. The problem is present in KDE 3.2 beta 2.

The initial idea of allowing to scroll form widgets when the mouse is on top of them is good. It saves you one click and I like to have it. You just have to differentiate it from the "user is scrolling page" situation and the timer looked like a good idea to me.

I hope this can get fixed.

Subject: kdelibs/khtml

CVS commit by mueller: 

CCMAIL: 45180-done@bugs.kde.org


  M +6 -0      ChangeLog   1.144
  M +5 -17     khtmlview.cpp   1.604
  M +15 -1     rendering/render_replaced.cpp   1.156


--- kdelibs/khtml/ChangeLog  #1.143:1.144
@@ -1,2 +1,8 @@
+2004-01-09  Dirk Mueller  <mueller@kde.org>
+
+        * rendering/render_replaced.cpp (eventFilter): readd the wheel event handling
+        which allows scrolling of the page again. Thanks a lot for just removing it. (#45180)
+        
+
 2004-01-02  Dirk Mueller  <mueller@kde.org>
 

--- kdelibs/khtml/khtmlview.cpp  #1.603:1.604
@@ -1250,8 +1250,8 @@ bool KHTMLView::eventFilter(QObject *o, 
                 default:
                     break;
-                }/*end switch*/
-            }/*end if*/
-        }/*end if*/
-    }/*end if*/
+                }
+            }
+        }
+    }
 
     QWidget *view = viewport();
@@ -1316,17 +1317,4 @@ bool KHTMLView::eventFilter(QObject *o, 
                 }
                 break;
-            case QEvent::Wheel:
-                if (w->parentWidget() == view) {
-                    // don't allow the widget to react to wheel event unless its
-                    // currently focused. this avoids accidentally changing a select box
-                    // or something while wheeling a webpage.
-                    if (qApp->focusWidget() != w &&
-                        w->focusPolicy() <= QWidget::StrongFocus)  {
-                        static_cast<QWheelEvent*>(e)->ignore();
-                        QApplication::sendEvent(this, e);
-                        block = true;
-                    }
-                }
-                break;
             case QEvent::MouseMove:
             case QEvent::MouseButtonPress:

--- kdelibs/khtml/rendering/render_replaced.cpp  #1.155:1.156
@@ -482,4 +482,18 @@ bool RenderWidget::eventFilter(QObject* 
             filtered = true;
         break;
+
+    case QEvent::Wheel:
+        if (widget()->parentWidget() == view()->viewport()) {
+            // don't allow the widget to react to wheel event unless its
+            // currently focused. this avoids accidentally changing a select box
+            // or something while wheeling a webpage.
+            if (qApp->focusWidget() != widget() &&
+                widget()->focusPolicy() <= QWidget::StrongFocus)  {
+                static_cast<QWheelEvent*>(e)->ignore();
+                QApplication::sendEvent(view(), e);
+                filtered = true;
+            }
+        }
+        break;
     default:
         break;

Is this verified fixed in 3.2?  I have 3.1.4 here, and I just accidently triggered a very similar behaviour.  To whit, I was moving my mouse around while reading, and idly scrolling at different points.  I didn't notice the mouse going over a list-box selector, and my scrolling caused it to change (no menu, no warning, just a change of the selected item), which caused a different page to load due to an OnChange JS selector bit.

If this patch in 3.2 fixes that case as well, then I don't have to open a new bug about mousewheel usage with selector boxes.

Didn't encounter the bug in a while, so I think it is fixed.