aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Avoid duplicate call to destroyv5.12.9Fabian Kosmale2020-06-091-1/+1
| | | | | | | | | | | | | | | Fixing the lifetime issue in emitDestruction led to a new issue: Setting linkedContext to nullptr before refCount has been incremented and invalidate has run can lead to calling destroy twice on the same pointer, and as a result to a use-after-free crash. Amends 0c8e51705ac0bb86c4b123ecd30a11b41fd50b24 Task-number: QTBUG-84095 Change-Id: Ib2ce76a45977217d0fb0f0e3ce06b24858b90468 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit a84537a159e9d3b9b66a9a0d4fdf3b1b9d3168d6) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Add changes file for Qt 5.12.9Antti Kokko2020-06-091-0/+46
| | | | | Change-Id: I49cf28dfc9be5511f16d4675f56c3759867e4981 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Prevent premature child destructionFabian Kosmale2020-06-051-2/+3
| | | | | | | | | | | | | | | | QQmlContextData::emitDestruction suffers from the fact that code can delete objects while emitDestruction is ongoing. Notably, the sequence child->emitDestruction can trigger a call to a->destruction (of one of child's attached components), which then can indirectly delete both child and child->nextChild (for instance, when a StackView gets cleared). We prevent this by using QQmlContextDataRef when iterating over the children, which keeps the child alive for the duration of the loop. Fixes: QTBUG-84095 Change-Id: I03a4e817904ba2735e1ffc15d509db95a1a4729e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit 0c8e51705ac0bb86c4b123ecd30a11b41fd50b24)
* qquickitemgrabresult: Check effective window for visibilityKai Uwe Broulik2020-06-021-1/+6
| | | | | | | | | | | When using QQuickWidget, the quick scene is in an offscreen window which isn't visible, so grabToImage would always abort with "item's window is not visible". Checking the render window for the item fixes that. Task-number: QTBUG-55879 Change-Id: I58153e02e78623ba4ea6e7beec18a7503de7feeb Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> (cherry picked from commit 7c9a54907f44b7e30ceac1975edcfa7920ffafd8)
* Rephrase Chunk::sortIntoBins() for more clarityUlf Hermann2020-06-021-4/+7
| | | | | | | | | | | | | | Assigning -1 to a quintptr so that it later overflows in another place when adding 1 warrants a comment. Also, assert against i overflowing the bitmaps. This way coverity might also understand what we are doing. Coverity-Id: 175402 Change-Id: I212110cbb784f89b1865bd0c0cc775c08cd40c04 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit 1c928f65ab9c7a495f84943ba1264acb4dbca0b8) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Prettify QV4_SHOW_BYTECODE output for JS classesUlf Hermann2020-06-021-11/+12
| | | | | | | | | | | Drop all the double spaces, force a line break after each class, and avoid converting empty strings to utf8. Coverity-Id: 190711 Change-Id: I789291e257aeac97c2a931bfc604f453c39906eb Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 512fde525ea5972bbae2796d6b2054fd370a5275) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Don't return a pointer to a local in QObjectWrapper::getQmlProperty()Ulf Hermann2020-06-021-1/+1
| | | | | | | | | | | | | findProperty() can optionally create the property on the fly. We store the result on the stack. In that case we can figure out that the property exists, but we cannot return its value. This is OK, as we do the same in the default case below. Coverity-Id: 193545 Change-Id: I3a87fc6f577807e2daf74eeacd2aab61f40aefc8 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 7645c8e0f88a83d021f0a327617189b7772b14eb) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Improve polish loop detection and diagnosticsJan Arve Sæther2020-05-262-7/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix handling of QQuickViewPrivate::rootUlf Hermann2020-05-252-23/+33
| | | | | | | | | | | | | | | | | | QQuickView is supposed to own the root item and shall also track it for external deletion. Therefore, when we assign a new root item we need to delete the old one. There is no point in setting a QPointer to nullptr after deleting it. It will do that by itself. When we fail to assign a new item, we should _not_ automatically delete the new one. Calling code typically does not expect the argument to a set* call to be deleted right away. Rather, return a boolean indicating whether we have successfully set the root object. This can then be used to get rid of the object if necessary. Coverity-Id: 218729 Change-Id: I79ed37d22d304bcc6d4e3c956b83a65fe157dfe0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit a64ee3a2481499f856d0f3fbc697399e0df1e8f8) Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix failing assertion in the GC with JITSimon Hausmann2020-05-221-0/+2
| | | | | | | | | | | | | | | | | | | | Commit d4edf441257b7e5782a6c25802d821647ffcba45 fixed the issue for architectures where the return value register overlaps with the accumulator register and thus clobbers it (x86-64, x86). The issue however persisted on ARMv7 (and in theory also ARMv8). Further investigation suggests that another source of clobbering of the accumulator register may be the caller of the JIT generated code itself, since we never explicitly initialize the register. So if one of the first byte code instructions is the creation of a call context or ConvertThisToObject - anything that saves the register to the JS stack frame - then we could end up with the GC trying to mark a value that contains garbage (or looks like a managed, typically). Change-Id: I719e189c3314c85adb23fb2ab2a0acf26a418d4e Task-number: QTBUG-83384 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit d12c2716064e1dc6013c175952a34146a69aa507)
* Fix failing assertion in the GC with the JITSimon Hausmann2020-05-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit db3dd029d7cd911712102efd5ea71868494f9f6f introduced the saving of the accumulator register on the JS stack in more situations. This unveiled another bug: When the physical ACC register contains garbage, we may end up saving it on the stack and thus making it visible to the GC. That one may trip with the infamous Q_ASSERT(m->inUse()) assertion failing when the value looks like a managed pointer but in fact isn't. So the question is: How can garbage end up in the physical ACC register? Thanks to a detailed bug report from David Faure, KDE's ktexteditor kateindenttest (testCstyle:comma6 in particular) triggered this situation when run with aggressive GC, where the prologue of a generated constructor function started with two instructions CreateCallContext ConvertThisToObject The first instruction is a call into the run-time with CallResultDestination::Ignore - it's a "void" call. The second instruction starts with STORE_ACC and also ends up allocating memory, triggering the GC when run with aggressive mode enabled. The problem here is the ::Ignore option for the return value. It means that the ReturnValueRegister is clobbered and may contain anything. If the ReturnValueRegister is the same as the AccumulatorRegister, then the STORE_ACC call later will end up writing "garbage" into the JS stack. As a remedy, this patch treats the ::Ignore case special and loads undefined into the ACC when the return value register and the ACC register are the same. Change-Id: I82c7a3456125f9c87e83abb9eb54465106873560 Task-number: QTBUG-83384 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit d4edf441257b7e5782a6c25802d821647ffcba45)
* JIT: Don't pass the heap object in the return value registerUlf Hermann2020-05-222-3/+6
| | | | | | | | | | | | | | | | | | | We have two variants for call destination results: Ignore or store in accumulator. The accumulator may be the same as the return value register. Therefore, when side stepping this mechanism and leaving the result in the return value register, we should have realized that we have to save/load the accumulator. We didn't and left the accumulator clobbered. A further fix actually clears the accumulator proactively after each call with Ignore if it is the same as the return value register. Now we don't get our result anymore in this case. To fix this, just use the accumulator register, declare that we do so, and save/load it around the call. Change-Id: I65fe4f7430ebfc419863b329bcd66a95875e5ffb Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix warning -Wxor-used-as-powMårten Nordheim2020-05-181-1/+1
| | | | | | | | | | | | Thanks clang 10 warning: result of '2^53' is 55; did you mean '1LL << 53'? [-Wxor-used-as-pow] Change-Id: I164ba4ac12d4ae9dbd6651d50b9f5d2c8928d049 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> (cherry picked from commit 50cd8cf97aa89a48a9fbaaeb2515e529e66c7d43)
* Check in even more places for exceptionsFabian Kosmale2020-05-184-3/+8
| | | | | | | | | | Amends commit 4c5ed04e64ea9ac0038ae30e1189cfe745b29bd9 Task-number: QTBUG-83384 Change-Id: I0918c27dfa73dff83cbf0f58b41ce8620dff8a0a Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit f31a2dc6fc713ee06ea7a9ba45c3ceaace7d735d) Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Ask rendering thread to release resources when window is closedDamien Caliste2020-04-301-0/+8
| | | | | | | | | | | | | | | | | | | If the close event is accepted, the close handler in QWindow will destroy the underlying platform window without notifying the QSGRenderer attribute windowManager. This may cause a race condition if the renderer is a QSGThreadedRenderLoop because the platform window may be deleted while the thread is using it. Correct this issue by notifying the QSGRenderer on a close event using the hide() method (which is supposed to release the resources according to documentation). Fixes: QTBUG-82474 Task-number: QTBUG-73929 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> (cherry picked from commit ca66d4fc23706a0f4ecfc4031f37cdd19facd836) Change-Id: Ia8d76a4471270ca90af7c201e7ad4477609b9c36
* Bump versionAlexandru Croitor2020-04-221-1/+1
| | | | Change-Id: I996530246190ba8767d3c57547a4c9b09df1e11b
* Blacklist tst_qquicktextedit::hAlignVisual on SLESFabian Kosmale2020-04-161-0/+2
| | | | | | Task-number: QTBUG-76719 Change-Id: I0979134b8a8fe8f8460a13ef1338991126537413 Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
* Merge remote-tracking branch 'origin/5.12.8' into 5.12Qt Forward Merge Bot2020-04-142-2/+46
|\ | | | | | | Change-Id: I064b346257bd24160f5b54770b2ee6ed6075e22d
| * Add changes file for Qt 5.12.8v5.12.8Antti Kokko2020-03-181-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | + ddeffeed1d933b6513f18533a9186e9f472da117 Remove shadereffect dependency from shapes + 03df41fbcdb6e1ae3d0792d5b7806e5335b58794 QML list property: Avoid crash if contained object is deleted + d5b6cf62be82727deff279f1b61b8ed238e3a214 Bump version + e9b4fac4e1765ea8789b17948a0a22fad7db50c0 Fix some ListView bugs related to snapping when it had a header + 0a155d14578d01bfe02fa9383745e04bfa1e5648 QV4MM: Fix crash caused by MarkStack overflow + cbd4456c9db70afda6c8408be7e5da800889d169 Fix warning about non-relative paths in qmldir files Change-Id: Ib245030ae96cdbd8143450283300e937fd951474 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
| * Check that value type exists before creating wrapperFabian Kosmale2020-03-161-2/+10
| | | | | | | | | | | | | | Fixes: QTBUG-82843 Change-Id: I1ea4a52b33e7d318525e63346eab46ecf7a8fec0 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit 5bcb2ff883f9f8ceb42ed6de298aa3036d6413b3)
* | ArrayPrototype::method_filter: Check for exception after callbackUlf Hermann2020-04-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | If there was an exception we cannot assume the returned value holds anything sensible. Also, we should immediately return. (cherry-picked from commit 31d05c6734057bed56ac783d4f9d03d3c2ecbcbb) Fixes: QTBUG-81581 Change-Id: I822c204c476e05d6de78124b66ab2f939ca38ffd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | V4: Check for exceptions before we use the result of a JS callUlf Hermann2020-04-0816-42/+99
| | | | | | | | | | | | | | | | | | If the call resulted in an exception the return value is undefined. (cherry-picked from commit 4c5ed04e64ea9ac0038ae30e1189cfe745b29bd9) Task-number: QTBUG-81581 Change-Id: Ibfdd5e1229cf5437f270232d3b1a91308adeec72 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Fix QQuickMouseArea getting stuck in pressed state when hiding in pressFrederik Gladhorn2020-04-023-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Check that animation still existsFabian Kosmale2020-04-023-1/+49
| | | | | | | | | | | | | | | | | | 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>
* | Fix signal emission order for zero-duration animationsJan Arve Saether2020-04-024-8/+83
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix warning about non-relative paths in qmldir filesSimon Hausmann2020-02-181-1/+1
| | | | | | | | | | | | | Permit the use of resource urls in qmldir files to allow for the use-case of a plugin including its .qml files in resources and optionally compiling them ahead of time. When the resources are bundled in the plugin, qmlplugindump might or might not work. Task-number: QTBUG-48809 Change-Id: Icb331c7575f26316b5c2bcc604b9c6d793977a9f Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit f15c2c22cb677677ccf8aacb2603fcf774d13584)
* QV4MM: Fix crash caused by MarkStack overflowFabian Kosmale2020-02-174-1/+57
| | | | | | | | | | | | | | | 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>
* Fix some ListView bugs related to snapping when it had a headerJan Arve Sæther2020-01-313-15/+817
| | | | | | | | | | | | | | | | 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)
* Merge remote-tracking branch 'origin/5.12.7' into 5.12Qt Forward Merge Bot2020-01-311-0/+41
|\ | | | | | | Change-Id: I6a7e59c3f2c9f7e5bd0b384b2d2c5e5ddc599ee0
| * Add changes file for Qt 5.12.7v5.12.7Antti Kokko2020-01-211-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 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>
* | Bump versionAlexandru Croitor2020-01-281-1/+1
| |
* | QML list property: Avoid crash if contained object is deletedFabian Kosmale2020-01-284-10/+67
| | | | | | | | | | | | | | Task-number: QTBUG-81123 Change-Id: I3dd1a42e444f817722368cd268c2f987a99fbf1c Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit e5570eecd3a4fc61020d28699169707a2c1f5dc9)
* | Remove shadereffect dependency from shapesKarim Pinter2020-01-233-3/+5
|/ | | | | | | | | | | | | Uses wavefrontmesh only if the shadereffect feature is there. Path doesn't need to depend on shadereffect feature only on gui module. The shape also missed a sgtexture header. Fixes: QTBUG-81296 Change-Id: I78425ef8a09226b99e9b9f6010dda9dac9009fe5 Reviewed-by: Andy Shaw <andy.shaw@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> (cherry picked from commit 39c614bed375d67f796d1519ebd2997060f81a0b)
* On QQmlEngine destruction drop singletons before type loaderUlf Hermann2020-01-143-2/+39
| | | | | | | | | 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)
* Merge remote-tracking branch 'origin/5.12.6' into 5.12Qt Forward Merge Bot2020-01-073-52/+68
|\ | | | | | | Change-Id: I2b6a5d21048f5e2af435ff0d32f68ce332cd04d3
| * Add changes file for Qt 5.12.6v5.12.6Antti Kokko2019-11-071-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + 4d080635872fbb77a2adfb736d3f108b62cc058a Remove HACKING file + 4b944cb61fb3ceee2f1b743823e4a83b686bafd6 Fix loading of ES modules when using CONFIG += qtquickcompiler + 0ec16fb93db6ad6792b3269838211485e8af464b Add missing HoverHandler docs + 8577f12bf4dfd9adfe8c5b85a3712bf1cc5ba0c3 Fix build with -no-feature-quick-sprite + 35acc9fc3c41446bacbbfe754f7f494de7f62411 QQuickTextNodeEngine: don't create background when its alpha is 0 + eeb00570679c447f4701a92cd2e836f098724979 Visit lists iteratively when parsing QML + db3dd029d7cd911712102efd5ea71868494f9f6f Fix various accumulator-saving problems + 44600c6b5da91a6b28f642486ca898b68fbdb675 Check if the filters are different before triggering an update + 72b95fc8cac5b9275317f4e5fe74f64aa97a3437 lancelot graphics test: various fixes + ee8f5482d6ba8ffa0faf2bbf25569d59f3467fc8 Revert accidental change to test262 + 2f16944d45e1ade14ad086a547a9673b1ceba7bc Allow semicolon after property declaration + 128ba80362be4e8cf13147307eb9c652c4b5f124 PathView: grab mouse on press if already moving + da74e8fbb91b680d7783daa1595baa3ecc92cb2e PathView: reduce velocity by linear decay model if release is delayed + 803151f460509332a1fc8142e1b7659a42f70690 Handle "interesting" stationary touchpoints as if they moved + 409807a022f65af86413ae09b5befff1eb99e727 Make QQmlValueTypeFactory::valueType() and isValueType() consistent + 4c42cedf8211f88689e784d52265eae21ba1e4ca Bump version Change-Id: I614f9e90ebf23cfd59273e53c46a0e40116b5e8b Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
| * Merge 5.12 into 5.12.6Kari Oikarinen2019-11-072-4/+38
| |\ | | | | | | | | | Change-Id: Ie0005eed1c1c85fb866b022e66bc35670dfb7a37
| * | QQmlVMEMetaObject: Scope MemberData for allocating writeUlf Hermann2019-11-062-52/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we need to allocate in order to write a property of the object, we need to make sure that the member data is not garbage collected during that allocation. Change-Id: I885cdc547588c1b20450e1586765cd0266b4c4f0 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 21844350df530a65071e8679d5e047adf553e0f7) Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* | | QQuickBehavior: Check that animation is not semi-deletedFabian Kosmale2019-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | TapHandler: don't reject stationary touchpointsShawn Rutledge2019-12-093-5/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | | Particle system: fix infinite loop after running for many hoursYulong Bai2019-12-092-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | MouseArea: react to touch ungrabShawn Rutledge2019-12-056-0/+241
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | | Set the screen on the QOpenGLContext to be the same as the windowAndy Shaw2019-11-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | | MultiPointTouchArea: stop ignoring Qt-synthesized mouse eventsShawn Rutledge2019-11-263-21/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | | Bump versionFrederik Gladhorn2019-11-071-1/+1
| |/ |/|
* | Fix bug when highlight was not respected after currentIndex changedJan Arve Sæther2019-11-042-4/+38
|/ | | | | | | | | | | | | | | | | | | | | 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>
* Bump versionFrederik Gladhorn2019-10-301-1/+1
|
* Make QQmlValueTypeFactory::valueType() and isValueType() consistentUlf Hermann2019-10-169-49/+105
| | | | | | | | | | | | | | | | | | | 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>
* Handle "interesting" stationary touchpoints as if they movedShawn Rutledge2019-10-103-2/+46
| | | | | | | | | | | | | | | | | | | | | | 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>
* PathView: reduce velocity by linear decay model if release is delayedShawn Rutledge2019-09-252-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | That is, from the time between the last mouse move event to the mouse release, the velocity will be linearly discounted/depreciated until it reaches 0 at QML_FLICK_VELOCITY_DECAY_TIME, which is currently 50 ms. 50 ms seems like a long time if the user meant to flick and release immediately (in practice it might be more like 4 ms), and also a short time if the user meant to "dwell" before releasing. If we try to translate the fake physics to real physics, this would be approximately equivalent to saying that if you slide a flat plate on an air hockey table with one finger, and then stop suddenly, its momentum _would_ cause it to keep moving under your finger for up to 50ms (except that it doesn't, because our timeline doesn't "tick" until after the release); and yet if you hold it for longer than 50ms, it will stop right on the spot. That's not quite realistic, but feels OK for fake physics (like the rest of the physics in Qt Quick). Also add the qt.quick.pathview logging category, which will just log the velocity calculations for now (but is intended for anything else in PathView that seems worth logging later on). Task-number: QTBUG-77173 Task-number: QTBUG-59052 Change-Id: Ie86f18d3b3305874b698c848290e0fd3beda94de Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> (cherry picked from commit 3df387d63421f09533ab72e2a73fb5d259693120) Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 03:09:08 +0000