aboutsummaryrefslogtreecommitdiffstats
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
* stabilize and standardize tst_qquickwidgetShawn Rutledge2018-06-262-19/+17
| | | | | | | | | | | | | | | In tst_qquickwidget::enterLeave(), start with the cursor outside the same as we do in QtQuick tests: move the window first, then position the cursor to the right of it and downwards (because the window might not necessarily go where you want it to). Don't hard-code 5000ms timeout on qWaitForWindowExposed(): it's the default anyway. Task-number: QTBUG-64397 Change-Id: I67e4566c2c7f9e361a79e3a091436c3391f39786 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickPathViewPrivate: fix heap-use-after-freeMitch Curtis2018-06-252-0/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The TabBar auto tests in Qt Quick Controls 2 repeats the following process very quickly for several data rows: 1. Creates a TabBar (PathView, when using the Universal style) 2. Moves items in its QQmlObjectModel 3. Deletes the TabBar When run with ASAN, this test would fail, because the TabButtons (which are child items of the PathView) would try to access a deleted QQuickItemChangeListener upon their destruction. The underlying issue is that QQuickPathView::modelUpdated() is called, and before a refill() can happen, the view is deleted. QQuickPathView::refill() was the only execution path that was releasing the cached items (QQuickPathViewPrivate::itemCache), and since part of releasing an item involves removing the QQuickPathView as a change listener from the item, the item would access the deleted view (listener) when the item was being destroyed. This patch fixes the issue by also releasing cached items in QQuickPathViewPrivate::clear(), which is always called by the destructor. Task-number: QTBUG-68964 Change-Id: Ic5bf0943be79948c86bf7c07ef13ecd1a7b971ba Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Robin Burchell <robin.burchell@crimson.no> (cherry picked from commit 49c244e3c5a9138e6785515ebb64334705236ed4)
* On network redirects, update finalUrl, not urlUlf Hermann2018-05-257-1/+49
| | | | | | | | | | | | | | | | We want all further imports to be relative to the redirected URL, not the base one. Note that this will incorporate any prior URL interceptions into the final URL if a redirect happens. We don't really want this to happen because the result of interception is not meant to be the base for further URL lookup. However, as interception occurs before redirection, this is unavoidable. Don't use URL interceptors on remote URLs. Task-number: QTBUG-67882 Change-Id: I6693d14c8af8212dda9954d0bd0293c3c85441ef (cherry picked from commit cda2680d801acce4e221b23e88d9b3c5504f86e8) Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* QQuickItem: Guard against null deref in transformationsRobin Burchell2018-05-022-0/+27
| | | | | | | | Change-Id: Ieb14322c104d816842e04e521b556bfc11855f1c Task-number: QTBUG-67024 Reviewed-by: Robin Burchell <robin.burchell@crimson.no> Reviewed-by: Michael Brasser <michael.brasser@live.com> (cherry picked from commit f9686bc68696ad1e99a0587f15d05300d003d990)
* Fix bug preventing ungrabMouse() on TouchCancelDaniel d'Andrada2018-04-091-20/+71
| | | | | | | | | | | | | | | | | | | | The order matters. There won't be a mouseGrabberItem() after the cancelExclusiveGrabImpl() call. So ungrab the mouse before calling it, not after. This cherry-pick includes some other changes to tst_qquickwindow.cpp (parts of 9d8fe2ac121162c15be6728495be2235b728325a) that enable the cherry-picked test function touchEvent_cancelClearsMouseGrab() to be the same as it is in 5.10 branch. Task-number: QTBUG-63680 Task-number: QTBUG-67445 Change-Id: I1ba6401c5d8eb3417907eb1e6ca20816b501f3ac Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry-picked from 0821180dc833376a738742e33f728983b9ca6f84) Reviewed-by: Tasuku Suzuki <tasuku.suzuki@qt.io>
* Fix out of bounds reads in Array.concatLars Knoll2018-04-031-0/+14
| | | | | | | | | | | In some cases, when our simple array data had an offset and data would wrap around, ArrayData::append would write out of bounds data into the new array, leading to crashes. Task-number: QTBUG-51581 Change-Id: I55172542ef0b94d263cfc9a17d7ca49ec6c3a565 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit f495d4b660107536d0a67ba48e88550278f13893)
* Handle function expressions as signal handlersErik Verbruggen2018-03-281-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two ways to use function expressions on the right-hand side of bindings: property var somethingPressed somethingPressed: function() { /* ..press something else.. */ } signal buttonPressed onButtonPressed: function() { /* ..handle buttonPress.. */ } In the former case, it declares a property that holds a function. So on initialization, the right-hand side of the binding returns a closure that gets assigned to the property 'somethingPressed'. In the latter case, the signal handler is explicitly marked as a function for clarity. So, the handler should not be returning the closure, but the handler should *be* the closure. In general, it is not possible to detect if the left-hand side is a property or a signal handler when generating QML cache files ahead of time. So for this case, we mark the function as only returning a closure. Then when instantiating the object, we check if it is a signal handler, and if the handler is marked as only returning a closure. If so, we set that closure to be the signal handler. This patch also handles function expressions in SignalTransition and function expressions as signal handlers. Task-number: QTBUG-57043 Task-number: QTBUG-50328 Task-number: QTBUG-50328 (cherry picked from commit 22b13921f8067f8a93164875a4ad59bed85b0400) (cherry picked from commit dc4d6293f9473c0f03c570430d08867d2d01c6e2) (cherry picked from commit 21301c1dbb00f4a2cd991e520423ed039b297ffb) Change-Id: I3008ddd847e30b7d0adef07344a326f84d85f1ba Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* QML debugger: Don't crash when creating objects on engine destructionUlf Hermann2018-03-191-0/+24
| | | | | | | | | | | You can create further objects while the QML engine is being destroyed. The debug service is not interested in those because they will be rather short lived anyway. Task-number: QTBUG-62458 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Change-Id: I255e18590d434e0487efac7c82c223752c645f25 (cherry-picked from commit 958e412a25523cc031564faae81c569aa6c3b01f)
* Fix JITted code for jump strict-not-equal undefined on 32bitErik Verbruggen2018-03-151-0/+21
| | | | | | | | | | | | | | The generated code for jump-on-strict-not-equal-undefined used the same logic (but with inverted conditions) as the equal case. For equality, one can jump to else if the value parts are not the same. So, for not-equal, if the value parts are the same, it would jump to the else block if they are the same. Meaning, an encoded int value of 0 (which is strict-not-equal to undefined) would end up being evaluated as equal. Task-number: QTBUG-66832 Change-Id: I5c6b8e9b11be53ae21a7164e0a1e0cbfd204f401 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix issue with bindings to aliases that cannot yet be resolvedErik Verbruggen2018-03-152-0/+25
| | | | | | | | | | | | | | | When an alias points to a child object which has not yet been initialized, it's id won't have been registered yet, so setting up a binding to it will result in a crash. The fix is: when setting a binding target fails, and its target property is an alias, queue them until all bindings have been set up, and try again. Task-number: QTBUG-57041 Change-Id: I4dc5a6d25c0a32fed9fd952c955e2006c76be45a Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit aa94c6c0469b0595f483f13ac88459f0035deef9)
* Allow setting values in value type group properties in "on" assignmentsSimon Hausmann2018-02-262-0/+28
| | | | | | | | | | | | | | Assigning to a group property inside a property value source or interceptor as part of an "on assignment" is perfectly valid. That is because while "color" is a value type property, the on assignment means we're actually setting easing.type (in the example and test) on the property value source, not the color, and that one is a QObject. The same goes for interceptors. Change-Id: I505a658977a578894d6dfb00bf5c65b41e42b12f Task-number: QTBUG-56600 Reviewed-by: Michael Brasser <michael.brasser@live.com> (cherry picked from commit 2659c308792967322564b5088e0e21bb371e0283)
* Fix ListModel.get(idx) == ListModel.get(idx)Simon Hausmann2018-02-231-0/+1
| | | | | | | | | | | | | | | | | | | This is a regression introduced with commit 4876ea6a18ccdfd72014582aa5d50ab9f6b6ec9e. Where we previously always returned the same JS object, we would afterwards return a new JS object for every invocation, which breaks reference comparison. As we store the JS wrapper for the list element in the QQmlData->jsWrapper we can avoid repeated allocations. In order for that wrapper to keep working after modifications (insertion, etc.) to the list model, we have to replace the static element index with a reference to the node model meta-object, which also has an element index that however is kept up-to-date by the list model itself. Change-Id: I4368de6b6d86687fe96fbf73bd60b80b69d7b058 Task-number: QTBUG-52017 Reviewed-by: Michael Brasser <michael.brasser@live.com> (cherry picked from commit 44a89492b49f23a975377795dbb7a48916cb5081) Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Remove superfluous assert when traversing IRErik Verbruggen2018-02-221-0/+13
| | | | | | | | | | | | When accessing/calling a property on an object, it is possible (and perfectly fine) for that object to be a constant value. I.e. Undefined. All code handling such a call do handle constants correctly. Note: this is a 5.9 specific change, because 5.11 got rid of this code. Task-number: QTBUG-66027 Change-Id: Ied9d0c9c8f8bf958f8634f7be196900b3ea64861 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Correctly set this object when calling scope/context functionsErik Verbruggen2018-02-152-0/+25
| | | | | | | | | | | | When a function is called that is in a QML scope or a QML context, set the 'this' object to the QML scope. Note: this patch is 5.9 specific. 5.11 has a similair issue, but the implementation is quite different, so that needs a separate fix. Task-number: QTBUG-59357 Change-Id: Ia78e012d413c40a094e957f4020502cd055ac286 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix memory leak with ListModel.getSimon Hausmann2018-02-131-0/+28
| | | | | | | | | | | | | | | | | | | This is a regression introduced with commit 3cc589c98390992e3ee8a7970dc2913ea857d623, which in turn fixed a leak with QV4::QObjectWrapper objects. Unfortunately the allocate() call into the persistent (weak) value storage in the list model introduced a leak of the weak value itself. This is fixed by replacing the free standing weak value allocation with the use of the existing jsWrapper weak value in the declarative data (QQmlData). That weak value is freed property in the destroy() method of the QV4::QObjectWRapper. The extra QQmlData allocation is hidden behind a unified allocation, similar to what we do in void QQmlType::create(QObject **, void **, size_t) const. Task-number: QTBUG-66189 Change-Id: I5351e3e484542709a6b210e84aa19b14d28e11ad Reviewed-by: Lars Knoll <lars.knoll@qt.io> (cherry picked from commit 22d43f74e264626d0c28654c42c91839f9de45b5) Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
* Fix memory leak with JS importsSimon Hausmann2018-02-093-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Strictly speaking this is a regression introduced with commit e22b624d9ab1f36021adb9cdbfa9b37054282bb8, making the QQmlContextData objects reference counted, especially from the V4 QML context wrapper objects. That change (correct as it is) introduced an accidental circular dependency in the simple scenario of importing a .js file in a .qml file: Each time the type in the .qml file is instantiated, we create a dedicated QQmlContextData for the .js file. If the .js file has no imports itself, that new context will get the same ctx->importedScripts JS array as the QML context of the .qml file. That is a strong reference via QV4::PersistentValue. That array in turn contains the QV4::QmlContextWrapper that belongs to the imported script, which in turn holds a strong reference (via refcount) to the script's context. This patch breaks the circular reference when we perform context invalidation, as the least intrusive measure. For the auto-test to work, we must also clear the qmlContext persistent of the QV4::Script that's used to evaluate the .js file. In subsequent imports that persistent will be initialized to new values, so it will only hold a strong reference to the last import, but strictly speaking that is still a leak - hence also part of this fix. Change-Id: I3e543c946e5e683425072dc3df7e49ca0e0c0215 Task-number: QTBUG-66189 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* tst_qquickflickable: fix compiler warningMitch Curtis2018-02-081-1/+1
| | | | | | | | | tst_qquickflickable.cpp:822:47: warning: ignoring return value of ‘bool QTest::qWaitForWindowActive(QWindow*, int)’, declared with attribute warn_unused_result [-Wunused-result] Change-Id: I39be58a1032e36f650ce2e008026faaf368cca3f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* touchEvent_propagation: remove some QWaitsShawn Rutledge2018-02-051-6/+3
| | | | | | | | I doubt it will make the test any less flaky, but may be an improvement. Task-number: QTBUG-53916 Change-Id: I3901ab26107abfd1420947392232243ad8c40ead Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QML: Collapse all NaNs into one single (encoded) NaNErik Verbruggen2018-02-052-0/+20
| | | | | | | | | | The idea of NaN boxing is to use one single NaN as a "true" NaN, and all others as a boxed value. So when encoding some NaN, be sure to use that one "true" NaN. Otherwise, it will be interpreted as an encoded value. Task-number: QTBUG-65998 Change-Id: Ia6e4641be180f3d626c40a57b473f181358e04db Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Add QQuickWindow synthMouseFromTouch testShawn Rutledge2018-02-031-0/+107
| | | | | | | | | Similar to the one for QQuickWidget, it tests the effect of AA_SynthesizeMouseForUnhandledTouchEvents and verifies the source() of the synthesized mouse event. Change-Id: Ib706b5cc7b9a374850f3197ca6ce2c3aed4d1ba2 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* add tst_qquickwidget::synthMouseFromTouch testShawn Rutledge2018-02-031-2/+117
| | | | | | | | | Make sure events are delivered as expected and that synth-mouse events have the right source(). Task-number: QTBUG-64241 Change-Id: I95a073ce0faea2111c8e1aca42fa44c1b529a6ec Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* If Loader loads Window, set its transient parent to the Loader's windowShawn Rutledge2018-02-023-0/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes the Item { Loader { sourceComponent: Window { } } } case consistent with the Item { Window { } } case: the inner Window is transient for the outer Window. It works even if the Loader's Window has a visible: true declaration: in that case, until now, the Loader's Window would become visible at component creation time, before the outer Item became visible. So the test to check whether it had a transient parent did not work. We now change the delayed-visibility mechanism in QQuickWindowQmlImpl to wait for the parent Item to acquire a window of its own rather than waiting for the transient-parent-if-any to become visible. It should still take care of all the old cases too, e.g. in the Window { Window { } } case, the inner Window's QObject parent is actually the QQuickRootItem. (Amends 701255c76f671f100338a799f0194bf10e26c9d1) [ChangeLog][QtQuick][QQuickWindow] When a Window is declared inside another Item or Window, the window will not be created until the parent window is created. This allows it to have the correct transientParent and be managed as a transient window. Task-number: QTBUG-52944 Change-Id: Iaf4aafbd696f6e8dd0eec1d02db8bd181483bd07 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix memory leak with QtQuick compiler generated filesSimon Hausmann2018-02-021-0/+18
| | | | | | | | | | | | | | | | When for the QQC code path we do QML type re-compilation, we allocate a new QV4::CompiledData::Unit. We must make sure that this dynamically allocated memory is released in QV4::CompiledData::CompilationUnit's destructor, by ensuring that the StaticData flag is not set. This isn't directly applicable to the ahead-of-time generated cache file unit data as they will always be re-generated (and thus the unsetting of StaticData at the end of createCompilationUnit::createUnitData()), but I've added a test-case nevertheless to ensure the correct engine behavior. Change-Id: I16973d7989567892bf8bf9dd6214bf293055d260 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix dead lock / race in QML type loader when importing pluginsSimon Hausmann2018-02-024-0/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When importing modules - in the QML loader thread - with plugins we keep globally track of the Qt plugins that we have loaded that contain QML modules, to ensure that we don't call the engine-independent registerTypes() function on the plugin multiple times. After registerTypes() we may also call initializeEngine() on the plugin for the engine-specific initialization, which - as a QQmlEngine is provided as parameter - must happen in the gui thread. For that we issue a thread-blocking call that waits until the gui thread has woken up and processed the event/call. During that time the global plugin lock is held by that QML loader thread. If meanwhile the gui thread instantiates a second QQmlEngine and attempts to issue a synchronous type compilation (using QQmlComponent::CompilationMode::PreferSynchronous), then gui thread is blocking and waiting for its own QML loader thread to complete the type compilation, which may involve processing an import that requires loading a plugin. Now this second QML loader thread is blocked by trying to acquire the global plugin registry lock (qmlEnginePluginsWithRegisteredTypes()->mutex) in qqmlimports.cpp. Now the first QML loader thread is blocked because the gui thread is not processing the call events for the first engine. The gui thread is blocked waiting for the second QML loader thread, which in turn is stuck trying to acquire the lock held by the first QML loader thread. The provided test case triggers this scenario, although through a slightly different way. It's not possible to wait in the gui thread for the plugin lock to be held in a loader thread via the registerTypes callback, as that also acquires the QQmlMetaType lock that will interfere with the test-case. However the same plugin lock issue appears when the first QML engine is located in a different thread altogether. In that case the dispatch to the engine thread /works/, but it won't be the gui thread but instead the secondary helper thread of the test case that will sit in our initializeEngine() callback. This bug was spotted in production customer code with backtraces pointing into the three locations described above: One QML loader thread blocking on a call to the gui thread, the gui thread blocking on a second QML loader thread and that one blocking on acquisition of the plugin lock held by the first. Fortunately it is not necessary to hold on to the global plugin lock when doing the engine specific initialization. That allows the second QML loader thread to complete its work and finally resume the GUI thread's event loop. Change-Id: If757b3fc9b473f42b266427e55d7a1572b937515 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Prevent invalid characters being entered at the appropriate timesAndy Shaw2018-02-021-2/+10
| | | | | | | | | | | | | | | | | When a validator does not allow for certain characters to be entered, then it should not allow these to be entered in even if an input mask is set. This fixes a regression introduced in 1b21b73e89942d567c90a17a3bf7a7ecae3de258. The test modified is because this is in fact a general limitation when combining validators and input masks, when a separator is used. Whereas the original patch did allow this to be possible, this is now not possible again. Task-number: QTBUG-64616 Change-Id: Ic6a3f40a9faa7c04abc055cfc2752044fddd33a0 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
* Disallow registration of types beginning with lowercase lettersMitch Curtis2018-01-311-0/+8
| | | | | | | | | | | | | | Allowing types with lowercase names causes ambiguity, as can be seen in QTBUG-43567 and the comment in IRBuilder::visit(), which explains that "the grammar can't distinguish between two different definitions" whose only difference is casing of the first letter. - Prevent registration (return -1 with e.g. qmlRegisterType()) when a type name doesn't begin with an uppercase letter. - Document the uppercase type name rule in more places. Change-Id: I4e522c65990f418eaafa45a256e3cb07a3e01ba4 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix exposure of -1 as enum value in QML exposed C++ singletonsSimon Hausmann2018-01-312-1/+11
| | | | | | | | | | | | | | | | | When a C++ singleton has an enum with the value -1, we would expose that value correctly when taking the accelerated property access code path in the optimizer, but when going through the slower QQmlTypeWrapper we would return undefined. This turned out to be a silly logic error that assumed that -1 is not a valid value for an enum and instead indicates an enum value not present. [ChangeLog][Qml] Fix -1 as enum value in QML exposed C++ singletons showing up as undefined. Task-number: QTBUG-66067 Change-Id: Ib66dad7a4b59822b2c40ad6bd9af4b72469582e9 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Michael Brasser <michael.brasser@live.com>
* Fix segfault when alias target refers to lowercase-named typeMitch Curtis2018-01-274-0/+17
| | | | | | | | | Create an error via QQmlCompileError and return it instead of asserting. Task-number: QTBUG-43567 Change-Id: I0c0741943d30516379eff5f44ed8618a0f0116a4 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Add README for tests/auto/bicMitch Curtis2018-01-271-0/+13
| | | | | | | Task-number: QTBUG-65827 Change-Id: I0c0b960066377acea5de2e45ac21675aab223c64 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* Blacklist tst_TouchMouse::buttonOnDelayedPressFlickable() on mingwUlf Hermann2018-01-181-0/+2
| | | | | | | | | It is flaky and needs to be fixed. Task-number: QTBUG-65823 Change-Id: I471754631493eed20400a2a57b7e55c5007e55f7 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* Merge remote-tracking branch 'origin/5.9.4' into 5.9Liang Qi2018-01-184-7/+57
|\ | | | | | | Change-Id: I2837d46455d8f82f0272b463fdf59a3fcfe53ea3
| * Use localPos for windowPos when passing mouse events to QQuickWidgetv5.9.4Ulf Hermann2018-01-172-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | QQuickWidget thinks of itself as a toplevel window, so it cannot process the offsets in a parent window. Amends 41293196b4db1aa7a0c616af312875c484639644. Task-number: QTBUG-65800 Change-Id: I8c5dcb8f44a6cbdb58bcc956d8263e68d8180bec Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
| * Blacklist test_move() in tst_qquickcustomaffector on win/gccUlf Hermann2018-01-172-7/+10
| | | | | | | | | | | | | | | | | | | | | | The test is unstable. Also, print the actual numbers if the fuzzyCompare QVERIFYs fail again. This way we can see better what is going on. Task-number: QTBUG-65819 Change-Id: I65368300498382f7bfebb25299280aa15e3a56ef Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
* | Fix crash when accessing a deleted objectMitch Curtis2018-01-112-0/+36
| | | | | | | | | | | | | | | | | | In QObjectWrapper::query(), return QV4::Attr_Invalid if the object was deleted. Task-number: QTBUG-44153 Change-Id: I53e8be6196489c323b190dbfa20d2dda2a54315e Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | GridView: Fix an off-by-one offset of positioning of itemsJan Arve Sæther2018-01-102-0/+157
| | | | | | | | | | | | | | | | | | | | The block for finding the position for the item *before* needs to be applied for the case where visibleItems is empty too, so we separate it out. Change-Id: I60a7e3a44d01a0087970e37bf4e73b94da5ebd48 Task-number: QTBUG-49218 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | lancelot: Add tests for some emoji casesEskil Abrahamsen Blomfeldt2018-01-102-0/+90
| | | | | | | | | | | | | | | | | | | | This adds a test that emojis can be mixed with non-latin scripts and that ZWJ correctly joins together emojis when applicable. Task-number: QTBUG-61882 Task-number: QTBUG-65519 Change-Id: I6d52382886c9a0c8f2d07ef56abad49ec2f2798e Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* | QQmlEngineDebugService: Actually call value types' toString() methodUlf Hermann2018-01-081-1/+2
| | | | | | | | | | | | | | | | | | | | QML value types generally are Q_GADGETs, but the userType we see there is the wrapped class's type, which doesn't have to be a gadget. So, the toString() method was rarely called, and a model index would still crash the debug service. Change-Id: I63778953eb9d2fc60113c11057da3047fc75a9bd Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Fix segfault on invalid property alias syntaxMitch Curtis2018-01-043-0/+8
| | | | | | | | | | | | Task-number: QTBUG-64798 Change-Id: Id1eb434f83ec89c5ea1ebaa4d8ec86fce9f4428f Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Allow QQmlComponent::loadUrl() to load absolute URLs with relative pathsMitch Curtis2018-01-044-0/+32
|/ | | | | | | | | | | | | | | | | | | | | Currently, QQmlTypeLoader::getType() will assert if passed a relative URL, because it needs absolute URLs in order to ensure that it can use them as keys for its cache. After dc6b73390 was merged, URLs like QUrl::fromLocalFile("main.qml") (which are currently used in examples of how to load a QQmlComponent) started causing the assertion to fail. As mentioned in the comments of the bug report, some patches have already been applied to QQmlComponent's QString-based constructors, but both the constructors taking a QUrl and loadUrl() itself need fixing. This patch puts the fix into loadUrl() (the constructors call this function) so that every operation involving URLs is successful when using the documented methods. Task-number: QTBUG-58837 Change-Id: Ib54ca52eddce6e7781cf96015f4c15af604233d3 Reviewed-by: David Faure <david.faure@kdab.com>
* Fix holistic benchmarkErik Verbruggen2018-01-021-3/+10
| | | | | | | | | | | Each test now uses its own QQmlEngine, instead of using a single instance across all benchmarks. The effect is that peak heap usage (on macos) is now about 77MB, where it previously peaked at 770MB. This benchmark would actually crash on some platforms due to excessive malloc/mmap usage. Change-Id: I214f7b9b3d8c5565c0578b82c9c144ec87ed0f2b Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix animation benchmarkErik Verbruggen2018-01-021-3/+3
| | | | | | | This was broken by 49a11e882059ee1729f776722e085dd21d378c36. Change-Id: Ic7f261bce5e35b3dbcbdaf0b8718e08c56e55b39 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Remove extra addrefMichael Brasser2017-12-293-0/+44
| | | | | | | | | The code was previously updated to use QQmlRefPointer, so we shouldn't explicitly addref. This allows more components to be correctly trimmed when needed. Change-Id: I15a961cfc456eeab5c791c8a282cc7e2852912cb Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Use potentially intercepted URL as ID for compilation unitsUlf Hermann2017-12-212-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | We generally have to pass a URL and a file name everywhere because the logical URL might be something else than the actual file being loaded. For example a QQmlFileSelector might modify the URL to be loaded for a specific file. This resulting URL, however, should not be used to resolve further URLs defined in the file loaded that way. As we need to access QQmlTypeLoader::m_url as string more often now, cache it and avoid frequent translations between QUrl and QString. Furthermore, QQmlDataBlob's URLs are changed to follow the same semantics. The finalUrl is the one that should be used to resolve further URLs, the url is the one used to load the content, and subject to any redirects or interceptions. This changes the semantics of URL redirects. Previously a redirected URL was used as the base URL for furher URL resolution. This doesn't work because redirection occurs after interception and interception should not influence the resolution of further URLs. We now use the original URL as base URL for resolution of further URLs and rely on the server to redirect those, too. Task-number: QTBUG-61209 Change-Id: I93822f820bed2515995de3cb118099218b510ca4 Reviewed-by: Michael Brasser <michael.brasser@live.com>
* Add test to QQuickShortcut when render window is usedKari Hautamäki2017-12-193-0/+181
| | | | | | | | | Add auto test for shortcuts when render window is used to draw QQuickShortcut. Task-number: QTBUG-64548 Change-Id: If2eb1f5618ae5f21477cc239acb42bc73ca7ec99 Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* QQuickItemView: Clear pending changes when refillingUlf Hermann2017-12-182-0/+122
| | | | | | | | | | | | | | | | | | | | | | | | | Generally the bufferedChanges are an "extension" of the currentChanges, which can just not be applied at the moment because we are in a layout phase. If we regenerate or clear the whole view in the mean time, the bufferedChanges become just as invalid as the currentChanges. On top of that, refilling can trigger further changes, part of which will be applied during the refilling. As that leaves us in an inconsistent state, we need to loop the refilling until no further changes are generated. As the changes might affect items that are already visible, and therefore not subject to refilling, we need to clear all the items before refilling in this case. In QTBUG-46488 things are added in the onCompleted callback of the delegates (by expanding the tree view, which translates into adding rows to the list view). Depending on where you add the new items, the list view might pick them up when iterating the model on refill() or it might create delegates for the same model entry twice. So, if that happens we need to discard the result and refill again. Task-number: QTBUG-46488 Change-Id: Ie4e0a731f7feda6aa962b6cb9a6cd5c3bf90486e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickList/GridViewPrivate::fixupPosition: don't set moveReasonShawn Rutledge2017-12-161-1/+14
| | | | | | | | | | | | | | | In QQuickItemViewPrivate::applyModelChanges(), if moveReason = QQuickItemViewPrivate::Other, then QQuickItemView::trackedPositionChanged() will fail to call d->setPosition(pos), which is normally what keeps the Flickable moving for a while. Leave the reason as-is (it will be SetIndex in this case), so as not to forget that we were actually trying to move down when the sequence window->polishItems() -> QQIV::updatePolish() -> layout() -> fixupPosition() did its part of the work of moving down. Task-number: QTBUG-62864 Change-Id: I1021e2ea39265de9e1285e2ee17c5733189ab939 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add the source directory as import paths in tst_qqmlimportUlf Hermann2017-12-111-3/+3
| | | | | | | | On shadow builds the QML components won't be found in the build directory. Change-Id: I0f524063537669f68e64fc6c04a6756ed1d130fd Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Pass the source directory in the plugindump testUlf Hermann2017-12-112-1/+2
| | | | | | | | On shadow builds this fails when just passing ".", because "." is the build directory. Change-Id: Iee84b73f2c4e5c8663d84d53b31f658501244dc9 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* grabMouse() and QQWPriv::removeGrabber(): be clear whether mouse or touchShawn Rutledge2017-12-052-0/+102
| | | | | | | | | | | | | | | | | | | | | | | The bug was that a MouseArea could be stuck in pressed state if a touch tap occurred simultaneously on a second MouseArea while the first was held pressed by the actual mouse. QQuickWindowPrivate::setMouseGrabber(QQuickItem *) had too little information to make the right choice in case the given item argument is null. It should not mean ungrab everything: in this use case, the mouse and the touchpoint can be pressing two different MouseAreas, and releasing either one should ungrab only the MouseArea that is being released. However the only place it was called with nullptr was in removeGrabber(), and in that context we are given all the information: which item to ungrab and whether we want to ungrab mouse, touch or both. It's better to have a little code duplication between QQuickItem::grabMouse() and QQuickWindowPrivate::removeGrabber() than to lose this information about which device(s) and Item to ungrab. Task-number: QTBUG-64249 Change-Id: I0710534a05f3ceeb66105a03ab0f32a61df8a522 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Add a means to unregister custom qml typesAndy Shaw2017-12-013-0/+209
| | | | | | | | | | | | | | | In cases where Qt is used in a plugin it is possible that a plugin will be unloaded while Qt itself is still loaded and as a result there is a chance that there will be conflicting types registered. Therefore, to ensure that plugins correctly clean up after themselves cleanly, we need to add a means to unregister qml types. This is intended to only be used when the user knows what they are doing. Task-number: QTBUG-56521 Task-number: QTBUG-56532 Change-Id: Ie396e522385004e6e9f3841e04f8072ff29cb15b Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-07 01:13:59 +0000