Version: 3.5.3 (using KDE KDE 3.5.3) Installed from: Debian testing/unstable Packages I have seen some bugreports reporting a behaviour behaving most similar to this one, but not even the same ... First here is my testcase: http://www.emtypage.de/konq_bug/ Beside the date-field click on the calendar icon. A javascript-calendar pops up partially overlapping the textarea. The parts overlapping lack of mouse-events, the other parts are fully accessible. Dragging the calendar ( drag-area is the bottom area ) out of the textarea resolves this malpractice. Trace of Konqueror is only reporting the line: QFont::setPixelSize: Pixel size <= 0 (0) This may be the result of the inifinite z-index behaviour, which is told to be fixed, but not sure.
Created attachment 16851 [details] patch. Channel some more mouse events through the dom. Qt is a mulish girl though, I can't convince her to stop changing the cursor shape.
SVN commit 557096 by ggarand: Channel more KHTMLWidgets mouse events through the dom. BUG: 129947 M +6 -3 khtmlview.cpp M +31 -3 rendering/render_replaced.cpp --- branches/KDE/3.5/kdelibs/khtml/khtmlview.cpp #557095:557096 @@ -1083,7 +1083,10 @@ QPoint p(x-absx, y-absy); QMouseEvent fw(me->type(), p, me->button(), me->state()); QWidget* w = r->widget(); - if(w) + QScrollView* sc = ::qt_cast<QScrollView*>(w); + if (sc && !::qt_cast<QListBox*>(w)) + static_cast<khtml::RenderWidget::ScrollViewEventPropagator*>(sc)->sendEvent(&fw); + else if(w) static_cast<khtml::RenderWidget::EventPropagator*>(w)->sendEvent(&fw); } @@ -1940,9 +1943,9 @@ case QEvent::MouseButtonPress: case QEvent::MouseButtonRelease: case QEvent::MouseButtonDblClick: { - if (w->parentWidget() == view && !::qt_cast<QScrollBar *>(w)) { + if ( (w->parentWidget() == view || ::qt_cast<QScrollView*>(c)) && !::qt_cast<QScrollBar *>(w)) { QMouseEvent *me = static_cast<QMouseEvent *>(e); - QPoint pt = (me->pos() + w->pos()); + QPoint pt = w->mapTo( view, me->pos()); QMouseEvent me2(me->type(), pt, me->button(), me->state()); if (e->type() == QEvent::MouseMove) --- branches/KDE/3.5/kdelibs/khtml/rendering/render_replaced.cpp #557095:557096 @@ -697,6 +697,31 @@ } } +void RenderWidget::ScrollViewEventPropagator::sendEvent(QEvent *e) { + switch(e->type()) { + case QEvent::MouseButtonPress: + viewportMousePressEvent(static_cast<QMouseEvent *>(e)); + break; + case QEvent::MouseButtonRelease: + viewportMouseReleaseEvent(static_cast<QMouseEvent *>(e)); + break; + case QEvent::MouseButtonDblClick: + viewportMouseDoubleClickEvent(static_cast<QMouseEvent *>(e)); + break; + case QEvent::MouseMove: + viewportMouseMoveEvent(static_cast<QMouseEvent *>(e)); + break; + case QEvent::KeyPress: + keyPressEvent(static_cast<QKeyEvent *>(e)); + break; + case QEvent::KeyRelease: + keyReleaseEvent(static_cast<QKeyEvent *>(e)); + break; + default: + break; + } +} + bool RenderWidget::handleEvent(const DOM::EventImpl& ev) { bool ret = false; @@ -712,8 +737,7 @@ int absy = 0; absolutePosition(absx, absy); - - const QPoint p(me.clientX() - absx + m_view->contentsX(), + QPoint p(me.clientX() - absx + m_view->contentsX(), me.clientY() - absy + m_view->contentsY()); QMouseEvent::Type type; int button = 0; @@ -763,7 +787,11 @@ // << " pos=" << p << " type=" << type // << " button=" << button << " state=" << state << endl; QMouseEvent e(type, p, button, state); - static_cast<EventPropagator *>(m_widget)->sendEvent(&e); + QScrollView * sc = ::qt_cast<QScrollView*>(m_widget); + if (sc && !::qt_cast<QListBox*>(m_widget)) + static_cast<ScrollViewEventPropagator *>(sc)->sendEvent(&e); + else + static_cast<EventPropagator *>(m_widget)->sendEvent(&e); ret = e.isAccepted(); break; }
*** Bug 106080 has been marked as a duplicate of this bug. ***