+ 1b5bb04b0e092a214328b90dae5eb15f128fb677 Bump version
+ 5dad0afa9e0905bd384878327f19cc7faf3d8d9f MultiPointTouchArea: stop ignoring Qt-synthesized mouse events
+ 33d93478aa2a53983dd6a02588db2dc0ccbe694d Set the screen on the QOpenGLContext to be the same as the window
+ ff6bd91f580fa5ddae2d02f32b9d83be4374a445 MouseArea: react to touch ungrab
+ e93a471dfde3c3b08d41eac53e595129ca520c68 Particle system: fix infinite loop after running for many hours
+ 6dff64714e3683c1af6164f99ffe23b3a0001be1 TapHandler: don't reject stationary touchpoints
+ d18f6c27af18c2cf4090b456349196e9f563e9b3 QQuickBehavior: Check that animation is not semi-deleted
+ 7ff9e3c3959c2ef1d7c95c8d2a1d277ccb2752a9 On QQmlEngine destruction drop singletons before type loader

Change-Id: I1ce787590e47c62f3d0781443b3c02ac449eefe3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>

The singleton destruction can trigger additional types to be loaded.

Fixes: QTBUG-80840
Change-Id: Ifa406b2a1cfd3b9e9b36e8005dfc0808eebf15cf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 3c23f5371a19991771bd29c27d377c6672e46cd1)

Change-Id: I2b6a5d21048f5e2af435ff0d32f68ce332cd04d3

QQuickPopup::~QQuickPopup hides its overlay in its destructor. If a
Behavior is installed on its opacity property, it will get triggered by
this. If the animation associated with the Behavior is a property of the
Popup, which is bound to a QML element, it will however be already partially
destructed, as QQmlElement<QQuickPopup>::~QQmlElement and in turn
QQmlPrivate::qdeclarativeelement_destructor will have deleted its
associated memory, before QQuickPopup::~QQuickPopup has been called.

As this does not set any pointers to null, it would seem as if the
Animation were still valid. To remedy this, we now check if the
animation is in fact marked for deletetion, and, if so, bypass the
interception.

Fixes: QTBUG-80070
Change-Id: I0e33262c6b3963c46e300ae76c05063c00ff258b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 991035ea1f00671d79c340a8a5c038e6aae1ece7)
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>

Multiple TapHandlers must be able to react to multiple touchpoints.
Often when multiple touchpoints are in contact, some of them will be
stationary.  In that case TapHandler should not give up its active
state, which is the result of returning false from wantsEventPoint().

This partially reverts commit dcc7367997e7241918cdf0c702c7bb8325eb1ad4.

Fixes: QTBUG-76954
Change-Id: I836baf771f09d48be8d032472b0c3143e8f7f723
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit 7cdc3727a2b01c59d0a9e19a3cfc4e226ac1ab77)

The infinite loop was triggered by several issues coincide together.

In short, the direct cause is the particle's born time and lifespan were
represented in 32 bit floats and not precise enough to pass aliveness check as
time grows large.

While the time grows large, the resolution of floating point decreases to the
extent that resolution is even bigger than 2 milliseconds.
Then it will fail to pass the aliveness check. Then, the
dead particles will be treated alive and they are kept inserting into and
popping out of the particles heap, which is similar to a live-lock.

The fix is to separate freeing dead and inserting back alive ones in two
different loops, ensure that the emitter can update time for next frame.

There are still other issues:
1) as the times runs very long, the particle needs several frames's updates
to actually make the states change noticeable, which means animation may
become not so smooth after running for too long (like several days).
May change particle's born/lifespan time to 64 bits in another patch.

2) the particle system's and animation's timers are 32 bit integers,
after 2^31 milliseconds(24.8551348 days), they will overflow. May promote
them to 64 bits in another patch.

3) as the time grows even larger such that the resolution is bigger than 16ms
at 60 hz frame rate, the live-lock may occur again. Because the timer advances/delta
will be not large enough to make dead ones reused.
The next live-lock estimated time is 2^24*16 milliseconds = 3.10689185 days.
The final fixes are 1) and 2)

4) may change the particle system's internal timer be set to arbitrary value
(fast forward to large value) for easier writing autotest for above cases.

Change-Id: I1190c0814c8197876b26dd4182dc4b065dd1ece6
Task-number: QTBUG-64138
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
(cherry picked from commit f8df9dc8b45cd9e386b66255183c58f3dfcc41a9)
Reviewed-by: Liang Qi <liang.qi@qt.io>

If an event handler (such as DragHandler) takes the exclusive grab
of a touchpoint that MouseArea had already grabbed as a synth-mouse,
it should react in the same way as if its grab of the actual mouse was
stolen: release the pressed state, etc.

Fixes: QTBUG-77624
Change-Id: I51f4fb253f7d0377be421c23e617942507616e72
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit 23df1603f514407d245a2740f32f589318ef654e)

This ensures that the QOpenGLContext has the right screen information
and can create a compatible context for use with QQuickWidget.

Change-Id: I9d78ff2b616e5c1d1c11d1da438ce336a0f24953
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 4080025fed9d43a78b578bcab67397712459d28c)

We ignored them because we assume that if a touch event is sent first,
the MultiPointTouchArea will handle it; and then if a synth-mouse event
is sent afterwards for some reason, it's irrelevant to MPTA.  However:
1) A synth-mouse event should not actually be sent, because MPTA accepts
the touch event. 2) If Flickable is used with pressDelay set, Flickable
will send the delayed press in the form of a mouse event (it does not
know how to replay a touch event at all). So if MPTA is used in a
ListView delegate for example, it's necessary for MPTA to react to a
synth-mouse event during replay. In both the press delay replay
and QTabletEvent scenarios, the mouse event has source() set to
MouseEventSynthesizedByQt, so MPTA needs to handle those events.

After a synth-mouse event during replay, MPTA can still receive an
actual touch release, which thoroughly confuses its pre-existing logic.
In that case it helps to check whether the touchpoint ID is the same as
QQuickWindowPrivate::touchMouseId, handle the release of that point, and
also release the internal synthetic _mouseQpaTouchPoint which was
remembered from the mouse press.

Fixes: QTBUG-75750
Fixes: QTBUG-78818
Change-Id: I8149f8b05f00677eb07a2f09b725b1db5f95b122
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit 0012f8bd152a36a67abc696465f27d612625b5d9)