The change in a7349e6433d092398d76cafa5408753f06892cd7 reduced the number of readbacks of reference objects by using connections to set the dirty state only when necessary. Establishing connections, however, comes at a cost and this introduced a regression in the delegates_item_childrenRect QmlBench benchmark. The mitigation introduced in this patch is to delay creating the connection. When a reference object is created, it does not read or create a connection but is simply marked as dirty. Only on a subsequent read from within a different statement than the reference object's creation's statement, does a connection get created. This keeps the benefit of reducing unnecessary reads on objects that are used multiple times while not spending too much on creating connections. This brings back the benchmark to its original level of performance. The referenceObjectChainReadsBackAsRequiredBasedOnParentSignals test was changed to expect 8 reads instead of 4. Since all the accesses are part of the same statement, no connection is ever created and more reads are required than before. The referenceObjectDoesNotFetchWithoutNotifyEventDateObject test is reformatted to separate the assignment from the reads. Otherwise no connection is ever created. The referenceObjectDoesNotLeakAConnectionToTheDestroyedSignalOnANotifyBindable test can be updated to expect 0 connections. With this change, we only connect if the reference object is read again from a different statement. Amends a7349e6433d092398d76cafa5408753f06892cd7 Fixes: QTBUG-140757 Pick-to: 6.10 Change-Id: I5d02ec6266c51fbbe5f2e01405081dd5a167a833 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This relies heavily on the documented fact that we only support trusted QML/JS content, meaning most files are only significant, not critical. This also extends to the handling of qmlc files (as in compilationunitmapper), as we store them in a user owned, non-shared cache directory – so any vulnerability there would already mean that an attacker has write-priviledges on user data. An exception is ArrayBuffer, which can be used with arbitrary user data, and should create a valid QBA. Fixes: QTBUG-136970 Pick-to: 6.10 6.9 6.8 QUIP: 23 Change-Id: I22033fe6ab4acf8362a8183e25b92331d45cb32c Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
When certain types are passed over from C++ to QML, QML converts them to a QML usable representation that keeps track of the original data. To do so, the QML representation of the object performs read/write-backs when required to ensure that the representation is kept in sync with the original data, by reading the latest data from the source or writing back changes that are performed on the QML side. Generally, the representation on the QML side cannot know when the original data was modified, so that it has to read the data again each time it accesses the representation to ensure that the latest data is available. The reads can be very expensive. For example, the following snippet: ``` JSON.stringify(foo) ``` Where `foo` is, for example, a `QStringList`, might need to read the data multiple times for each element in the list. For representations that provene from a QObject's property that has a NOTIFY signal, it is possible to cut down on the number of reads by reading only when the data was effectively changed since the last read, that is, the NOTIFY signal of the property was emitted. Similarly, if the property is a BINDABLE, we can subscribe to the BINDABLE itself to track whether a change was performed or not. Thus, to reduce the number of reads when possible, `ReferenceObject`, the base representation for objects that perform read/write-backs, was modified to take into account the NOTIFY signal or BINDABLE status of a property when referencing data that originally provenes from a `QObject`'s property on the C++ side. `QObjectWrapper`, `QQmlTypeWrapper`, `ReferenceObject` and `QMLValueTYpeWrapper` were modified with the usual `Q_MANAGED_TYPE` macro, to allow identifying instances of those objects, which is used to enable the new implementation. The intializer for `ReferenceObject` was modified to behave differently when the referenced data comes from a `QObjectWrapper`, which wraps a `QObject` provening from C++, or a `QQmlTypeWrapper`, which can wrap a `QObject` that is a singleton or an attached property. When it is so, and the part of the wrapped `QObject` that is referenced is a property that has a NOTIFY signal or is a BINDABLE, the `ReferenceObject` instance will now connect to the signal or subscribe to the BINDABLE. A newly added flag, `isDirty`, will be set when the signal is emitted and is used to track whether the data has changed since our last read. `QV4::ReferenceObject::readReference`, the base implementation for read-backs, was modified to take into account the new "isDirty" flag. When the flag is not set, we expect to already have the latest data, and thus do not actually perform the read anymore. Furthermore, the same implementation was modified to take care of setting the `isDirty` flag to a correct state after a read is performed. The connection to the NOTIFY signal is performed through the existing `QQmlNotifier/Endpoint` infrastructure, which allows, between others, to connect to signal emitted by a `QObject`, and should be more performant than a naked connection. Similarly, a BINDABLE is subscribed to by using its usual interface. A new callback was added to be used by `ReferenceObject` to allow setting the `isDirty` flag on the signal emission. `ReferenceObject` will now store a `QQmlNotifierEndpoint` or a `QPropertyNotifier`, that will take care of listening to upstream changes and set the dirty flag as required. A few bug-provening test cases where added to `tst_qqmllanguage` to test that the number of unnecessary reads was indeed reduced. Additional test cases were added to inspect certain aspects of the new implementation to ensure that it works in certain common or edge cases. The internal documentation for `ReferenceObject` was modified to mention this new behavior. Fixes: QTBUG-118847 Fixes: QTBUG-127322 Change-Id: Id62979ae4e03910e1165c293837e5d884727dddc Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
All reference objects should be detached when written to a property of a QML-defined type. This is in line with what happens if you write the same object to a property of a C++-defined type and doing anything else makes very little sense. In particular, before this change, the behavior differed between ahead-of-time compiled code and interpreted code, between writing to "var" properties and writing to typed properties, and between different kinds of lists. Now everything we recognize as reference object always gets detached when writing to a property. [ChangeLog][QtQml][Important Behavior Changes] Writing a list or value type to a QML-declared property now always detaches this same list or value from any locals or other properties you may have read it from. Therefore, subsequent changes to its "source" will not affect it anymore. This is in line with what we do to C++-declared properties. Fixes: QTBUG-127957 Change-Id: Icdf188ef29d28e5d3aaa8219cc003e07e8813f38 Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Most FunctionObjects do not actually need their custom jsCall members. They will only call the functions from the vtable anyway. FunctionObject can therefore be split into a static and a dynamic variant. Only the dyanmic variant needs to carry (and invoke) the extra pointer. The jsCallWithMetaTypes pointer is completely pointless because none of the dynamic functions actually implement it. Furthermore, the QV4::Function and QV4::ExecutionContext pointers in FunctionObject are only needed by actual JavaScript functions. The builtins that like to be dynamic functions never need them. Therefore, split out another class for this. In the generic FunctionObject, we need the capability to decide at run time whether the function shall be a constructor or not. Add a flag to replace the check for jsCallAsConstructor. Also, where we can, avoid the pessimization of checking whether a function is a constructor before trying to call it as constructor. Rather have the default implementation throw the exception. As a side effect, for most functions we don't need an ExecutionContext anymore. The engine is enough. Task-number: QTBUG-124662 Change-Id: Iac657fa71288dd6ec230a33de2986ba3bcf4628c Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Task-number: QTBUG-117983 Change-Id: I5790f01d614cd70c7fcc9bd817ec6ace3f3e3730 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is the equivalent of JavaScript's valueOf(). Change-Id: If850519d6dbc7354b447acb6aad8ac04211d059d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Sami Shalayel <sami.shalayel@qt.io> Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
We map Date to QDateTime and special-case its constructors. Task-number: QTBUG-111624 Change-Id: I0496f853613da3ccee9b6f6c4cf0adffa064f9f8 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Since JavaScript has no concept of time or date separate from the Date object that contains both, and since we implicitly (via QVariant::convert) or explicitly accept string arguments to all these methods, we should really accept string coercions of Date objects. We should also make all the string overloads explicit. Converting strings to QDateTime is a really obscure feature of the metatype system. We should not rely on it. Furthermore, we need to accept QDateTime, as the native representation of the JavaScript Date object, as argument to formatDate() and formatTime(). Otherwise there are two ambiguous paths to calling formatTime() or formatDate() using a Date object: Either coerce the Date into a string and call the string overload or coerce it into a QTime or QDate and call the QTime or QDate overload. The QML engine special cases this and prefers the QTime/QDate way, but this just needlessly complicates the overload resolution. Interestingly, tst_qqmlqt already tests most of those variants. We just have to add the JS string coercions. Task-number: QTBUG-109380 Change-Id: I880e622256fe115dade32bde880605df2031ff2f Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
We should always use the same conversion to string and we shouldn't duplicate the code for the date conversion. Task-number: QTBUG-109380 Change-Id: I1b1959c8e9b5957ddcf287d252b8143511237565 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>