Merge lp:~aacid/oxide/qt54_variantjs into lp:~oxide-developers/oxide/oxide.trunk
Status: | Merged | ||||
---|---|---|---|---|---|
Merged at revision: | 954 | ||||
Proposed branch: | lp:~aacid/oxide/qt54_variantjs | ||||
Merge into: | lp:~oxide-developers/oxide/oxide.trunk | ||||
Diff against target: |
82 lines (+30/-11) 2 files modified
qt/quick/api/oxideqquickwebcontextdelegateworker.cc (+18/-9) qt/quick/api/oxideqquickwebframe.cc (+12/-2) |
||||
To merge this branch: | bzr merge lp:~aacid/oxide/qt54_variantjs | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Chris Coulson | Approve | ||
Review via email:
|
Commit message
Adapt to behaviour change in handling of QVariants from QML to C++ in Qt 5.4
[QTBUG-40431] When a JavaScript object/array is passed to C++ through
a QVariant, the engine no longer immediately converts the object
recursively into a QVariantMap or QVariantList but instead stores a
QJSValue in the QVariant. This prevents a loss of data when the JS
object contains non-primitive types such as function objects for
example. Code that expects the variant type to be exactly
QVariant::Map or QVariant::List may need to be adapted. Registered
conversion functions however ensure that code that merely calls
toMap() or toList() continues to work. Fixes: https:/
Looks good to me, and I’ve verified that the unit tests still pass with Qt 5.3.
Haven’t tested with Qt 5.4 yet.