For kinetic wheel events, Qt tries to make sure that all events in the
stream go to the widget that accepted the first wheel event.
It did so by directing all events from the stream to the widget from
which the spontaneous event was returned as accepted.
However, that widget might have passed the event on to some other
widgets; e.g QScrollArea forwards wheel events from the viewport to the
relevant scroll bar. The event might then have come back accepted only
because parent propagation kicked in (the scrollbar might not accept
the event, so the parents get a chance, and some parent's scrollbar
ultimately accepts the event).
In this scenario, the wheel widget would be the viewport under the
mouse, when it should have been the scrollbar of the parent. The
next events from the stream were then delivered to a widget that didn't
scroll; and parent propagation is not (and should not be) implemented
for the case where Qt has a wheel widget.
Instead, make the first widget that accepts any initial wheel event
the wheel widget, even if the event was not spontaneous. With this
change, all events from the stream are delivered to the widget that
actually handled the event. That has the effect that ie. a viewport
of a scroll area only gets the first event; all following events are
delivered directly to the scrollbar.
The test case added simulates the different scenarios - nesting of
scroll areas, classic wheel events and a stream of kinetic wheel
events.
[ChangeLog][QtWidgets][QApplication] Wheel events from a device that
creates an event stream are correctly delivered to the widget that
accepts the first wheel event in the stream.
Change-Id: I5ebfc7789b5c32ebc8d881686f450fa05ec92cfe
Fixes: QTBUG-79102
Pick-to: 5.15
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
bc205d81e7
