| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
Change-Id: Iefb900b42cc0476e62342724a5f3a480c09ce354
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When visible items become invisible, ListView will try to cache
them and redisplay these items if necessary. However, we can't
cache items when changing to a new model, since the old one will
be deleted later
Fix by adding a flag to let ListView know we are clearing items
and prevent cache unnecessary items
Fixes: QTBUG-80203
Change-Id: I50dcd3f0586c93496b143bdad0e59751360501a8
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem was that the screen position was changed by the user
and it did not check this before it set it to that saved position.
Also added a warning if it is still happening - which is not expected
anymore.
Fixes: QTBUG-79323
Change-Id: Id3d945626461016d51fcad9f8882c3d39544a985
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Writing an onWheel() handler script was working and mentioned briefly
in docs; but PointerScrollEvent and the signal were not documented.
Also fixed the type of QtQuick::WheelEvent::inverted: bool not int.
Fixes: QTBUG-81302
Change-Id: I31342955c42e20ff52460a1b7ee95da325e38af6
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QQuickMultiPointHandler inherits from QQuickPointerDeviceHandler, which
inherits from QQuickPointerHandler that already has a marginChanged
signal. It's the only place that signal gets actually emitted from.
Amends da722fb448f06cf43780e6f857a1ccd9f07176d6
Change-Id: I8ba3129ed69903d6f3cff56401c8a18580af0375
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
If a QVector has been modified from the outside, all its iterators are
invalid. Therefore, we need to do index-based iteration here.
Change-Id: I02b850daf6aadd8f8a81cc93b0d295e1170d7dd6
Reviewed-by: Simon Hausmann <simon.hausmann@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>
|
| |
| |
| |
| |
| |
| |
| | |
Before it would only output "Type Error".
Change-Id: Ibd3a85f327c3ce8c58295c7e900c516b77c85a2b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
Fatal because of -Werror.
Change-Id: I535848be1c733c0718779c8a4c8c93ed3873cc88
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|/
|
|
|
|
|
|
|
|
| |
When calling isSaveable() for a user based type then it should
return false because the client will not be able to read these
types. This prevents it from using the wrong streaming operator
for the user types then.
Change-Id: I7f3bff359dd0c3fa49dc4e83db0057b79c481ed9
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
| |
Change-Id: I370b4c4bd0d7962878849ca7c5edef6cb36eca25
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
| |
We could just crash there, assuming unlimited memory, but as this
particular place seems to be a very attractive target for various
mischief, let's just plug it.
Change-Id: I3b0369ceb34dafd12ce8dc1f189fc5f9ee82c169
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-81109
Change-Id: I97f37c68d33f414d7bffa9b66e0aaed93370dc68
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-81108
Change-Id: I7e121776a2416b5338c4c1309ec7cc31c703ad28
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
| |
This was fatal because of -Werror.
Change-Id: Ibe06f77d4728268af3f099554f7151bdaf9ac26b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes two crashes and a memory leak in QQuickItemParticle.
The first crash was caused by the list m_loadables that kept pointers on
QQuickParticleData, that could in the meantime become dangling pointers
if the associated particle expired or got deleted by a call to the
reset() method of the particle system. Its role was to keep a list of
particles that did not have a delegate instantiated yet, in order to
create them in the tick() method. This list is removed and the list of
particles to handle is directly deduced in the tick() method.
The second crash was caused by the list m_deletables that could in some
situations (generally due to a reset()) contain multiple times the same
delegate, and therefore cause a double delete in processDeletables().
This list is changed to a set to avoid this situation with a minimum
impact on the rest of the code.
The memory leak was caused by the m_managed list of delegates that was
not freed when QQuickItemParticle gets deleted.
Task-number: QTBUG-71193
Change-Id: I6fe30ee59a9a0bb90c14c62c7a48a50f465a9e0c
Reviewed-by: Mikhail Svetkin <mikhail.svetkin@gmail.com>
|
|
|
|
|
|
| |
Fixes: QTBUG-81105
Change-Id: Iaf0597cea3a5572f020c5f87a843774f33cc01fd
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
| |
Creating new ScopedValues in the loop was quite wasteful, and would
trigger a crash. We now simply reuse the ScopedValue.
Fixes: QTBUG-81104
Change-Id: Ie1efd144886861a21c8f6827d7fd23699a1e0dcc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
| |
Change-Id: I18b7a4e00150f6c47c991a5164901159b7f946b9
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Change-Id: I4d00865f25a989c380f4f5b221f4068c80b71d2b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
| |
Otherwise we try to assign an invalid RegExp object, which crashes.
Change-Id: I85478406524a2a9d7542758caaa1b42b4090bb93
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
| |
setArrayData() needs to handle a nullptr argument.
Change-Id: I1ea05d9db9beb1fede6d3c068cfcf700702e8aa6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
As we have already determined that we're past the end of the allocated
space on the source object by checking os->values.alloc, we should
conclude that all the remaining values are undefined.
Fixes: QTBUG-81037
Change-Id: I664f22b7eb37c26061e8a9e2f88bcf2a7b6e09f3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
| |
This uses the existing infrastructure for reporting QML errors, instead
of simply using qWarning.
Fixes: QTBUG-81093
Change-Id: Ie18656a57f28fa9dfe922936fd05b44ebe1281e2
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
| |
Turns out, we actually do not need to capture anything
Change-Id: I6194b45a1e8053be079d25a6d81212fa226fd3ea
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
In XMLHttpRequest, we need to get the QNetworkAccessManager from the
engine. However, if the request originates from a WorkerScript, there
exists no qmlEngine. We therefore add a new indirection to access the
QNAM, and set it up accordinly in registerWorkerScript.
Fixes: QTBUG-81055
Change-Id: I8915202b6d6b7139c8386304b3d1d7a22a82045e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
| |
While running the fuzz tester, a crash was found related to the fact
that the subFocusItem was already partially deleted.
Task-number: QTBUG-34779
Change-Id: I62c48cf40baabc9f0a81074cc6408e9073459165
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-74602
Change-Id: I08e8df96b10fbc0b58fbdae296c9d54de977e3f9
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The QAbstractItemModel may be nullptr, in particular when it gets
deleted from the outside. In some places we did check for that, via
operator T* from QQmlGuard, in others we didn't. The checks were quite
hard to read as "if (model)" first invokes a conversion operator on a
base class and then implicitly converts the result to bool. Similarly
adventurous, "if (*model)" invokes operator* on a base class and then
converts the result to bool.
Make all the checks explicit, and add new ones where they were missing.
Also, as we already retrieve the AIM in order to check it for nullptr,
re-use it for the actual operation.
Task-number: QTBUG-80963
Change-Id: I3548e22e9d2bef485a1cd4acf70839eb8e599e62
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
8704c640946ac852668638e2980d3e2b78aa27ae introduced new conversions
via sequentialIterableToJS. Due to that, QVariant properties which
formerly stored e.g. std::vector<QObject*> now would store a QJSValue.
Those would still claim to support a conversion to QVariantList, but
-contrary to what our documentation says-, we were not able to do a
conversion to QSequentialIterable. The default constructed
QSequentialIterable would then crash when calling begin(), as that
function pointer was null.
This patch fixes this by adding the necessary support to convert a
QJSValue containing an array.
Non-array QJSValues will still return an "empty" QSequentialIterable.
Note that this changes what happens when a QJSValue is converted to a
QVariantList, as QVariantValueHelperInterface<QVariantList> will check
first if there is a converter to QSequentialIterableImpl before
attempting to call any directly installed converter to QVariantList. In
order to not change the existing behavior, the QSequentialIterable
returns the QVariant corresponding to the QJSValue at a given array
position, intead of a QVariant containing the QJSValue.
Fixes: QTBUG-80609
Change-Id: I8101229c0d2043b3f2d618ed035b279844802dd8
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
| |
Change-Id: Ic9cd7e4ff2c5d253879b0aeaa15dbc25cad82891
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|\
| |
| |
| | |
Change-Id: Ibd935bf31aa2bcb2e4051c865ab946daeeeecddb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Consistently check that job->data is not null before derefencing it.
Fixes: QTBUG-80510
Fixes: QTBUG-79937
Change-Id: I894503ddd2254814463073cc12f8365641efc689
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
IdentifierReference could resolve to both ImpordBinding and
IdentifierName, causing ambiguity in the grammar, and ultimately
caused parse failues when parsing an import statement.
This is now resolved by explicitly telling the parser to prefer
shifting.
This is a partial cherry-pick. Apparently the effect observed in the
original change and fixed inline can also be triggered in different
ways.
(cherry-picked from commit 41bbf7e376d0e374dc7c4e2a5ed4157a1b880b4a)
Fixes: QTBUG-80423
Change-Id: Iaec29c452b577312248a17cb48f005f4fc0bd8c4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The code checking if the intermediate move distance was less than
the drag threshold, but without accounting for negative distances.
Since the negative distances were naturally less than the drag
threshold, the intermediate distances were set to zero and the
intermediate moves were never done.
In practice, this means that mouseDrag() never did intermediate
moves (i.e. what happens during a drag in real life) for drags
that go from right to left or upwards.
Task-number: QTBUG-80152
Change-Id: Ic27021f5ce5ba2937e95fb2dfb532bd2136f4205
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit fad8ef3e4133538e3785d7067c35c652bc894711)
Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is a continuation of af090d8, making sure the same dpr snapping
is done in the core profile shaders.
Change-Id: Iccd19a377968fb7bfbd49c3ef13b72284a48bab1
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is a bit more convoluted, but boils down to no-opengl + no-vulkan.
Task-number: QTBUG-80692
Change-Id: I508116721ae8ea5013546f20ac89b67929305b52
Reviewed-by: Liang Qi <liang.qi@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
No one should remove this at() before Qt6.
Task-number: QTBUG-80535
Change-Id: I464c6f675dc68ad9762fcb594bb4d6ba6bdaf316
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
| |
| |
| |
| |
| | |
Change-Id: I9c436f408562faaf74e2301ae93e25a0c4e9b22e
Fixes: QTBUG-80692
Reviewed-by: Johan Helsing <johan.helsing@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Runtime is nowadays only a collection of static methods, there is no
point in having it as a member anymore.
Change-Id: Ibe9fba3c7e52fbc0b16b6a5d717dd2d23ab21088
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
From before we would bail out early from the rebuild process if we
detected an empty table. A result from this is that we left
both contentWidth and contentHeight unchanged.
This patch will set an empty content size when the table is
empty. The effect will be that the user cannot flick the view
around based on the old size.
Fixes: QTBUG-80505
Change-Id: I3ac080476269fd5906ce79fa007eabb59b5ff4b1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As it stood, we would wait to release loaded items until we started the
rebuild process, if the old model was a DelegateModel. But at that time,
the model would alread have been changed, so we would release the items
by calling out to the wrong model.
This patch will ensure that we always release the items immediately when
syncing the model, which will also cover the case when the model is a
DelegateModel.
Fixes: QTBUG-80570
Change-Id: I1b06011f4795727d04d9cd8c20381f65552b8fe8
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Normally you either assign a model to TableView that
already has a delegate (or don't need one), like
DelegateModel or ObjectModel. Or instead you assign
a QAIM model and a delegate directly. But if you
assign both a delegate and an ObjectModel, TableView
would be confused, and ignore the assigned model
and instead create an internal wrapper model that
ends up empty.
This patch will ensure that we don't create a wrapper
model in such cases, but instead forward the
delegate to whichever model is assigned, even
if it ends up as a no-op for models that don't
use one.
Task-number: QTBUG-80534
Change-Id: Idd220df08617c379dc7808ee1f41c862b78cc201
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The scenario:
- mouse press: MouseArea grabs; DragHandler gets a passive grab
- drag a little: DragHandler's drag threshold is exceeded
- drag some more: DragHandler tries to take the exclusive grab
This grab takeover succeeded before, because although MA has
keepMouseGrab(), the event being delivered is a touch event,
and MA does not have keepTouchGrab().
If this happens while QQuickWindowPrivate::touchMouseId is the
same touchpoint that the DragHandler is trying to grab, it should
not succeed, because we honor the keepMouseGrab() flag. I.e.
keepMouseGrab() implies keepTouchGrab() whenever the touchpoint
under consideration is currently the touch-mouse.
On the other hand, if a DragHandler is used on some item inside
a Flickable: on press, the Flickable grabs right away (it has a
bad case of FOMO), but the DragHandler just gets a passive grab.
When the drag threshold is exceeded, DragHandler must be able to
steal the grab from Flickable, because Flickable was just being too
aggressive. So now we have the rule that if the Item it wants to steal
the grab from is a parent of the type that filters all events,
it's OK to ignore the keepMouseGrab() flag and steal anyway
(as it did before this patch).
Fixes: QTBUG-79163
Change-Id: I2b3f175bea867cb737357857657653b0a7b83995
Reviewed-by: Jan Arve Sæther <jan-arve.saether@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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As the variable was manually set to -1 beforehand, we would never emit
the change signal, leaving bindings stale. However, simply removing the
assignment would lead to not triggering the signal when currentIndex was
0. So now we set it to -2, which cannot happen in any other place.
Note that QTBUG-64998 was already mostly fixed due to earlier changes
fixing the currentItem part, only currentIndex was still broken
Fixes: QTBUG-68232
Fixes: QTBUG-64998
Fixes: QTBUG-63422
Change-Id: I885e06f1e258e67c3368d017bf79bff760440863
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, the code generator would truncate the stack slots when
writing the compiled function, as that one only had a 16bit field for
them.
Also, add a debug-mode check for stack overflows to the interpreter.
Unfortunately, as it triggers a stack overflow, the test will not
reliably fail without this change.
Fixes: QTBUG-80511
Change-Id: I3019bb2de657ae4c3e1040db798a83533f854bff
Reviewed-by: Paolo Angelelli <paolo.angelelli@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When moving an item from ObjectModel A to ObjectModel B, polishes are
scheduled for the respective ListViews in order: the ListView for A
first, and then the ListView for B. However, when it comes time to
do the actual polishing via updatePolish(), the list of items is
traversed backwards. This means that the following calls
var item = objectModelA.get(0)
objectModelA.remove(0, 1)
objectModelB.insert(0, item)
will result in updatePolish() being called for ListView B first, and
then ListView A. As a result of this, setCulled(false) will be called
by ListView B (since the item is now visible within it), followed by
ListView A calling setCulled(true) (since the item is now no longer in
it).
As there is no way for these models to know about each other (and it's
not feasible to store refcounts in QQuickItemPrivate::extraData, since
ObjectModel is in QtQml.Models, which can't know about QtQuick), this
patch makes ListView check if the item is parented to its contentItem
before culling it. This prevents it from hiding items which are no
longer shown in its view.
Change-Id: If50614ebc269fae875195bbc63c0c04dab237775
Fixes: QTBUG-67986
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the grabbed Item is released and then grabbed again,
if ungrabMouse () is called, the animation stops. In order to
avoid this, when ungrabMouse () is called, if offset is different,
it is modified to animate.
Task-number: QTBUG-79592
Change-Id: I61cbd4dad90643722f12480f0dab3859ce116af8
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|