| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing warning was pretty much useless since it would only warn
after having looped INT_MAX times. In addition, it didn't actually
detect if polish() was called from within updatePolish().
Instead, the counting is changed to be strictly more correct:
The counter is now only increased when polish() is called within the
updatePolish(). It will reset back to 1 if that does not occur.
Effectively, the counter will reflect how many consecutive polish loops
we have processed.
This patch will show diagnostics after having reached 1000 consecutive
polish loops. It will only warn for the next 5 items in order to not be
too verbose...(most likely they will be the same 5 items).
If the counter reaches 100,000, we break out of the loop:
This might be important for e.g. CI runs so that the process can actually
terminate in order to get some useful diagnostics.
Note that the item that calls polish() within updatePolish() doesn't
have to be the same item as updatePolish() was called on. We also want
to track these since there might be several items working in tandem to
create the loop.
With this change it will now give the following output:
main.qml:10:5: QML Row: possible QQuickItem::polish() loop
main.qml:10:5: QML Row: Row called polish() inside updatePolish() of Row
(This is when Row called polish() from within its own updatePolish())
Fixes: QTBUG-40220
Task-number: QTBUG-83856
Change-Id: Ib8a7242908082c70d8cf71efbbe1fa148dbfada0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit 1c8bce285522e0dcfd13fe6c514f4756d6d6438c)
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-76719
Change-Id: I0979134b8a8fe8f8460a13ef1338991126537413
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 78c1fcbc49f56463064eef738a475d9018357b24 we stopped giving the
exclusive grab to hidden or disabled items which is good. But the change
did not take into consideration how mouse area handles its internal
state.
As a simple example: A mouse area that would set itself hiding in the
press handler, would continue to have d->pressed == true, which means it
would not react to any future press events.
The fix is to let mouse area check in its change handler whether it has
become invisible.
The test also checks that enabled behaves the same way. There is no
action needed, since mouse area does completely custom handling of
enabled (maybe something to fix in Qt 6), disabling a mouse area doesn't
disable its children for example, it doesn't invoke
QQuickItem::setEnabled at all. Due to this circumventing the common
behavior, by chance disabling a mouse area in the on pressed handler
works.
Fixes: QTBUG-74987
Change-Id: Idb8499b3e5bcb744fbba203fdea5c46695bd5077
(cherry picked from commit 8ace780b5aa298e3c01903bfd57f766a42209191)
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
| |
Fixes: QTBUG-76749
Change-Id: Ie5eed240e8190a7297f71f5e40870a007e737d1d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
(cherry picked from commit 732b63ed0cd38feebd17978abde2843eddd2b7b2)
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The order for non-zero-duration animations are:
* started()
* runningChanged(true)
* stopped()
* runningChanged(false)
* finished()
This patch tries to ensure that zero-duration animations have the same signal
emission order.
The problem was that when setRunning(true) was called on zero-duration
animation, it would call itself (setRunning(false)) lower in the call stack in
order to immediately stop again. This had the implication that we could emit
stopped() even before started() was emitted (since the recursive call to
setRunning(false) would actually complete before the ancestor stack frame
setRunning(true) was completed)
To fix this we emit started() *before* we call start() on the animationInstance.
There is still a bug in that runningChanged(true) is still not emitted for a
zero-duration animation, but this patch should improve the current behavior in
the sense that stopped() is not emitted _before_ started().
Task-number: QTBUG-48193
Change-Id: Ic2bc85e648e6746f6a058e2e9136515e7fdb6192
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 8e0711cafd7e78c6e5d77fdda6be91135a355cd1)
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MemoryManager::collectFromJSStack did push to the mark stack without
checking if there is actually still space available. To fix this, we now
drain the stack once we hit the limit.
The test case is a slightly modified version compared to the reported
one, removing one loop. This was required as our regular expression does
not throw an exception when there are too many capture groups. However,
to trigger the bug, looping was not actually necessary.
(cherry-picked from commit e72b032cc1c5a8a07a99fc6522a692c36f369abc)
Change-Id: I4d00865f25a989c380f4f5b221f4068c80b71d2b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most bugs were related to the PullBackHeader header positining mode, for
instance the old code did not take into consideration that for the
PullBackHeader it was sometimes not sufficient to scroll the view. The
header also had to be scrolled independently from the view:
We achieve this by hooking on to the same timeline that is used for
scrolling the view. (This way, both animations are synchronized, and
they start and end at the same time).
Change-Id: I75708c0fd8d4741032c04ad9ee144d7a49cf3359
Fixes: QTBUG-76362
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit 01660fbb67c39c74b2e1eeae1e3d1b97c8886cdb)
|
|
|
|
|
|
|
| |
Task-number: QTBUG-81123
Change-Id: I3dd1a42e444f817722368cd268c2f987a99fbf1c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit e5570eecd3a4fc61020d28699169707a2c1f5dc9)
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QQuickListViewPrivate::fixup() seems to only do "fixup" if
moveReason != QQuickListViewPrivate::SetIndex
By default, moveReason is set to Other. In the snippet given in
QTBUG-77418, this is why the highlight was respected when resizing the
ListView initially. However, after the currentIndex was changed,
moveReason was changed to SetIndex. When we then resized the ListView, it
still had the value SetIndex, and would fail to "fixup" properly.
Since the ListView preferredHighlightBegin is bound to width, we should
set moveReason to Other in the property setters that are related to
highlight. This is then consistent with how setCurrentIndex() does it (it
similarly sets d->moveReason = QQuickItemViewPrivate::SetIndex;)
Change-Id: I7edf77fc977e8c7e3fc656ff5bb22b4dd01afbe4
Task-number: QTBUG-77418
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If isValueType() returns true, we should really return a non-null value
from valueType(). Otherwise the assumption that
QQmlValueTypeWrapper::valueType is never null breaks. In particular, the
unknown type and various primitive types are _not_ value types. We
special case the, probably common, UnknownType and check the actual
return value of valueType() for anything else. In order to avoid looking
up the metaobject each time we request a type that is not a value type,
we keep an invalid value type as marker for "not checked yet" and
replace that with nullptr once we determine that the type in question is
indeed not a value type.
Fixes: QTBUG-76866
Change-Id: I797f4cdd4db48ffc1b8fa2d919afc8022f67fa94
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
(cherry picked from commit f862b3edeb8a96a49a5d12620506d33d5a5aadca)
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Qt Quick will not receive "uninteresting" stationary touchpoints, but
only those in which some property has changed. So MultiPointTouchArea
should react to stationary touchpoints in the same way as if they moved,
so that UIs can react to changes in touchpoint velocity, pressure etc.
And QQuickWindow has to be willing to delivery stationary touchpoints
to make this possible. However when a QTouchEvent is customized for
delivery to a specific Item, by including only the touchpoints that
are inside the Item, then if those touchpoints are all stationary,
the event only needs to be delivered if at least one of them is
an "interesting" stationary touchpoint. So we need to depend on
a new per-touchpoint flag that QGuiApplication will set when it
discovers that some property of the touchpoint has changed. That is
QTouchEventTouchPointPrivate::stationaryWithModifiedProperty.
Fixes: QTBUG-77142
Change-Id: I763d56ff55c048b258dca40d88283ed016447c35
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit ae346195efaca5d01b67c5df1209512c7edaddb0)
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A side effect of 8fd398c9d2f5f54e446e0b402bc63a2edb50da6f is that it
became possible for the highlight to stop between items, rather than
snapping to a specific item, if the user taps, clicks or drags an
additional time while the movement is ongoing. That was because it
didn't get a mouse grab, so it missed the release event.
QQuickPathViewPrivate::handleMouseReleaseEvent() needs to take care of
the snapping behavior after the user stops dragging. This only affects
behavior in the case that the PathView is already moving and the mouse
is pressed again: we assume the user wants to alter the PathView's
velocity, not interact with any delegate inside or with any parent item.
Task-number: QTBUG-77173
Task-number: QTBUG-59620
Change-Id: I7b2f69a6ef8d8022d7c917a5bf9e8fb40c8848db
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
(cherry picked from commit e2df4233a77ce8a37d2c8ef26b7b42fc0d33a24b)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the rules already had Semicolon at the end, however it was
missing for UiScriptStatement, list properties and UiObjectInitializer.
This change fixes the regression from 5.11.3 to 5.12.0, and keeps the
behavior consistent.
(Semicolon was only introduced in 5.14, that why we need to introduce
the rule in 5.12 first)
Fixes: QTBUG-77954
Change-Id: I45ef35fab399e3f971444b96d4a9ec6a99e29e09
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 45b1a3f97953fac65c6aef8e46abad865a0d0bc3)
|
|
|
|
|
|
|
| |
(amends commit 7b47350736f46c59d81238d3d6284358a652983b)
Change-Id: I485f643d89b10ab70128fe199f900432138bfec8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prepare for new host info mechanism, support shadow build and install,
and fix screengrabs being distorted on Windows.
Squashed cherry pick of:
ac3698ae6aaac437e21f3ce08117ea6eedb148dc
04d92f9f9c16ace63a33ee18756ab8d40a1c1a66
144193549a3a47ea3ade74289e3adc55c2bd65e6
Change-Id: Icc382c0d59e8c68613d1f0aea2a60be712615e01
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|\
| |
| |
| | |
Change-Id: I6f456baf6bade7cdc66529c2b28d914c47929941
|
| |
| |
| |
| |
| |
| | |
Change-Id: I147d3faefac8114e08a0594a0c43b3cdae959804
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the alpha value for the background color of a text element is 0,
we don't need to create a rectangle node to represent it, as the
rectangle will be invisible anyway.
[ChangeLog][QtQuick][QQuickTextNodeEngine] don't create a new
rectangle node as the background of text, when the alpha of it is
0
Fixes: QTBUG-76137
Change-Id: I40c624ee8f61740fd07e7d3751a78b6224882913
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added the missing lookup for cached .mjs files in
ExecutionEngine::compileModule. This allows using .mjs files in
WorkerScript {} elements in conjunction with the Qt Quick Compiler and
also fixes the use when using QJSEngine::importModule.
[ChangeLog][QtQml] Fix loading of EcmaScript modules when using the Qt
Quick Compiler.
Fixes: QTBUG-77761
Change-Id: I58130b0468f4920b2f6c49b98a2f51d5ae3a0491
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An image inside at the end of a text block which did not start at text
position 0 would resolve to an invalid QTextLine, since we passed
the document position to lineForTextPosition(), which expects the
relative block position. If the image was aligned to top or
bottom, so that the extracted QTextLine was actually accessed,
this would cause a crash.
[ChangeLog][QtQuick][Text] Fixed a bug where aligning an image
to "top" or "bottom" could cause a crash under certain circumstances.
Task-number: QTBUG-77217
Change-Id: Iaa239ba482f2a765703656e4116cbebb8435a66e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
This would break importing older versions of a module, as we would try
to locate a singleton which does not exist in this version.
Fixes: QTBUG-77102
Change-Id: I78be1ec111d2be26a14b2a94bbf743cf6238cddd
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because centerOnScreen asks the window manager to move the window, but
does not wait for it.
This is applied in the same spirit as this change in qtquickcontrols2:
https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/268200
These tests appear slightly flaky on the Grafana dashboard, this commit
might help.
Change-Id: I30d3f4717aca435c94fb1a447c4b5c51021da3be
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The view uses a visible items list, which is maintained by the refill()
method, to determine which items should be triggered to do the populate
transition. The refill() was only invoked when component completed
before doing the populate transition; but if the size of the view
depends on the size of window (for example, using anchors.fill), more
delegates could become visible after component completed. In such a
case, part of visible items were not be triggered to do the transition.
[ChangeLog][QtQuick][Item Views] Item views such as ListView now properly
populate delegates with a populate transition when the view is resized
after componentComplete.
Fixes: QTBUG-76487
Change-Id: Id90c3f73d9911c8a1d6d8b1ea0c51f6c27d0ed5b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-71329
Change-Id: I261b25ff281bb44d03650ab05258743f104f3cc9
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
| |
Implicit capture of 'this' in [=] is deprecated in C++20.
Fix by using explicit captures.
Change-Id: I49b0fd2751c1d239c4f801224b71872c227fd697
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reverts what's left of e53510944169ac9f6753e0d14e1b24a24ff7bd9a
(amends 73258eca7ab7e3981d9f4aaa5484020cb67854a0):
MultiPointHandler is not only for touch handling anymore.
DragHandler in particular needs to respect the acceptedButtons property.
Fixes: QTBUG-76875
Fixes: QTBUG-76582
Change-Id: I414e785dd09b297c93e5e9f162be23e4a44eca54
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't want it to hold its position indefinitely after the button is
released. But in practice, reset() gets called again anyway in
QQuickSinglePointHandler::handlePointerEventImpl(), _after_
handleEventPoint(), which means after tapped() is emitted. Having the
point hold its position that much longer is convenient for applications
and more consistent with the state expressed by the release event.
Also amend the documentation.
Partially reverts 17237efaefabe924599abe00e92d8b54032d7915
[ChangeLog][Event Handlers][Important Behavior Changes] TapHandler.point now
holds the release position while the tapped() signal is emitted.
Fixes: QTBUG-76871
Task-number: QTBUG-64847
Change-Id: I621a2eba4507a498788e9384344e8b4b7da32403
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already took care of cases when the handler is a child of the Item,
grab transitions involving Flickable etc.; but the bug is about a simpler
case when the handler is in the parent of the item that has the grab,
and steals from it. Amends 38a016c7b1337d83d77879f45b4a2e6fec11d049
Fixes: QTBUG-71218
Fixes: QTBUG-75025
Change-Id: Id1d6d370e0db75c59ec7dce4a8e545701c501827
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Otherwise the path might get interpreted as some other part of the URL,
for example the host name.
Fixes: QTBUG-76441
Change-Id: I3edde96153403962db4576e5af794419c21b49a8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Avoid a crash when setData or create are
called after a user mistakenly used the internal constructor of
QQmlComponent which does not take an engine.
Fixes: QTBUG-55407
Change-Id: Ia4295d1b044723efce1a95607349561d4f1640da
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting the KeyNavigation.up property of an item to another item will
implicitly set the reverse (KeyNavigation.down) property on that other
item pointing back to the item. Once the item is destroyed, you will
have an invalid pointer stored in the other item pointing to the
destroyed item.
Using QPointer<> instead of raw pointers fixes that issue, because
they will become null on QObject's destruction.
Added QQuickItem test that verifies the issue is solved.
Fixes: QTBUG-75399
Change-Id: Ibb3e976c4eb9fcd81604bcc2eb757257d3653930
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 7cb6dce1f3e140ea68d6b05281950f212fc99d38 introduced an
optimization to remove bindings that after their initial evaluation had
no dependencies or errors (such as when accessing properties not set
yet). However when accessing a context property in a silent way -- using
typeof -- then no error state is set and the binding is removed. Any
later change of the context property results therefore in no binding
re-evaluation. This patch skips the optimization on bindings that are
associated with a context that has unresolved names. This fixes the
concrete bug at the expense of disabling further optimizations in the
context if other bindings access unresolved context properties. However
since context properties are discouraged anyway, this may be an
acceptable price to pay.
Change-Id: I95e120a4f71e8ebe0ec1fc44e8703c75f920dd28
Fixes: QTBUG-76796
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
| |
Change-Id: I2745d3df4fca77483313c70e5433339c444c7fd4
Fixes: QTBUG-76627
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
The refill() method would bail out early on an empty model. Make sure
that it at least updates the header and footer in such situations.
Fixes: QTBUG-31677
Change-Id: I1f3a1848ff263a8f7f9ccfc3b20f16b61348f57b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cause was that fast flicking kicked items in and out of viewport,
while in transition, they would abruptly having tracking data structure
, i.e. releasePendingTransition of QQuickItemViewPrivate, got iterator
invalidated. This also helps to resolve QTBUG-44308.
Fixes: QTBUG-76433
Fixes: QTBUG-44308
Change-Id: If14533d3f6b1acd7b6ca0c5c723347c0cb3f54dc
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just like resolving the lookup initially, we need to set the base also
when hitting the cached lookup code path. The base is then used as this
object.
Fixes: QTBUG-76656
Change-Id: I6f6be05bc9875ddccc6e112e91176a0fa24a8fa1
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
| |
At the point the plugin is actually unloaded the hook turns into a
dangling pointer.
Fixes: QTBUG-71387
Change-Id: Ib8ccee3f9a86d4700fbea7e87c666cd8f30f71e4
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The root cause was that the QAbstractAnimationJob::finished() might delegate its
destruction to change.listener->animationFinished(this), and the original author
was aware of that and provided a RETURN_IF_DELETE macro to return early if itself
got deleted. In the bug's case, change.listener->animationFinished(this)
dispatched to QQuickItemViewPrivate::animationFinished() which called
QQuickItemViewPrivate::release() and deleted the QAbstractAnimationJob object
itself in the end.
However, any objects derived from QAbstractAnimationJob, or holding a pointer
to a QAbstractAnimationJob, may potentially fall into the code path calling
QAbstractAnimationJob::finished(). Any QAnimationJobChangeListener that directly
or indirectly deletes QAbstractAnimationJob should be very suspicious to this
kind of "heap-use-after-free" bug. Should ensure that the QAbstractAnimationJob
won't be referenced after deletion.
In the bug's case, within the code path triggered by ListView displacement
animation, the other affected classes by QAbstractAnimationJob are:
QQuickItemViewFxItem, QQuickItemViewTransitionableItem, QQuickTransitionManager.
To fix this, a new SelfDeletable class is factored out to simplify the self-deletion
test logic. Any affected classes are made to have a public member m_selfDeletable.
Any code paths that finally reach QAbstractAnimationJob::finished() are
wrapped with related util macro.
Change-Id: Idd33fc3f2d529fd7d8bb088c329101b1e70dd6c0
Task-number: QTBUG-44308
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
|
|
| |
We don't use the accumulator in that method. It could contain any random
value.
Fixes: QTBUG-75642
Change-Id: I41f958c1174cce76d0d77e14d5617d441aaf1e11
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QVariants are commonly passed around between threads and QVariants can
wrap QJSValues. Therefore we need to allow this. The persistent value is
freed immediately if we're still in the same thread. Otherwise a
message is passed to the QJSEngine that owns it. If there is no
QJSEngine we assume that we can free the value immediately. As such a
thing can only happen via private API we can make sure this assumption
holds.
Fixes: QTBUG-75939
Change-Id: I14c09fd5d6ef7ba689f66656f2bcbb5c88bacf89
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
| |
The zoom factors passed to the preview service are interpreted as
absolute values, not as relative to the base zoom factor. The test would
fail if the base zoom factor was != 1.
Change-Id: If66d8c79dea91e4013e1ab7f790fa308ac87c934
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
| |
The wording of the warnings were changed in qtbase.
Fixes: QTBUG-76152
Change-Id: Iae0dfbcbb699b8abff92b5923b0a5627591043c8
Reviewed-by: Liang Qi <liang.qi@qt.io>
|
|
|
|
|
|
|
|
| |
When qml file is in resources, translations under i18n was not loaded
Task-number: QTBUG-76085
Change-Id: I75315ceb6a1e6ab10309634a3c445a82476d525c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
| |
Change-Id: I37d313e3156a44eb4487b1be007aa93ace18d882
Fixes: QTBUG-76018
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
The triggerUpdate call was incorrectly removed by merge 42f485231c
Fixes: QTBUG-68566
Change-Id: Ibf37d88315d3ef9879e6cb9728a1c4ef4655c72b
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, populate their "name" property directly from the surrounding
object pattern if applicable, without adding locals. This fixes some
ecmascript tests where functions were assigned to the key "eval" in an
object. The JS engine then rejected that because you shouldn't use eval
in strict mode. That should be close enough to test for regressions.
Fixes: QTBUG-75880
Change-Id: Iacc45a3f7b0eb90cddc6ecf6d2bada616d2cf355
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|