- 
    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)
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).
