Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.9.6, 5.15.2, 6.0.0 RC
-
None
-
Win 7
-
-
9ba4c6beeff394d8526503b43ba471d82c27df9c (qt/qtbase/dev) f4093e05136a65c6812815706f0041d2b2d88a9e (qt/qtbase/6.1) 9b976a5029a1b3bf5c118cd4407220e74730479e (qt/qtbase/6.2)
Description
Reproduction:
- create a QGraphicsView 'myView' with an movable QGraphicsItem on it (i.e. with flag QGraphicsItem::ItemIsMovable)
- scroll (manually) in a manner so that the item covers view position (0,0)
- call QScroller::scroller(myView)->scrollTo(...)
→ nothing happens
Reason is (see Qt source 5.9.6):
call QScroller::scrollTo
→ call !d->prepareScrolling(QPointF())
→ a QScrollPrepareEvent is sent
→ the QScrollPrepareEvent is received by QAbstractScrollArea::event():
case QEvent::ScrollPrepare: { QScrollPrepareEvent *se = static_cast<QScrollPrepareEvent *>(e); if (d->canStartScrollingAt(se->startPos().toPoint())) { ...
→ canStartScrollingAt is called with position QPointF() == (0,0):
QGraphicsItem *childItem = view->itemAt(startPos); if (childItem && (childItem->flags() & QGraphicsItem::ItemIsMovable)) return false;
→ return false
→ so the call '!d->prepareScrolling(QPointF())' in QScroller::scrollTo retuns false, and no scrolling occurs
I think the solution should make a difference between 1) software scroll (i.e. a call of QScroller::scrollTo) and 2) a user scroll per mouse. The test 'QAbstractScrollAreaPrivate::canStartScrollingAt' makes only sense for case 2).