Ubuntu
qtdeclarative-opensource-src package

API versioning broken in some cases

Bug #1389721 reported by Chris Coulson on 2014-11-05

This bug affects 3 people

Affects		Status	Importance	Assigned to	Milestone
	qtdeclarative-opensource-src (Ubuntu)	Confirmed	High	Unassigned
	qtdeclarative-opensource-src (Ubuntu RTM)	New	Undecided	Unassigned

Bug Description

With Oxide 1.2 being the version that's shipping in the RTM image, I want to start correctly versioning new API's so that we can upgrade Oxide OTA safely without breaking existing applications. I'm testing the attached patch for Oxide to add a revision to API's that were added in 1.3, but running the test suite results in the following failure:

Output:
----------------------------------------------------------
file:///home/chr1s/src/oxide/oxide/qt/tests/qmltests/core/tst_CustomURLSchemes.qml:11:11: ".allowedExtraUrlSchemes" is not available due to component versioning.
       context.allowedExtraUrlSchemes: [ "test", "bar" ]
               ^
********* Start testing of qml-core-test *********
Config: Using QtTest library 5.3.0, Qt 5.3.0
QWARN : qml-core-test::tst_CustomURLSchemes::compile()
  /home/chr1s/src/oxide/oxide/qt/tests/qmltests/core/tst_CustomURLSchemes.qml produced 1 error(s):
    /home/chr1s/src/oxide/oxide/qt/tests/qmltests/core/tst_CustomURLSchemes.qml:11,11: ".allowedExtraUrlSchemes" is not available due to component versioning.
  Working directory: /home/chr1s/src/oxide/oxide/objdir/qt/tests/qmltests
  View: QQuickView, import paths:
    '/home/chr1s/src/oxide/oxide/objdir/out/bin'
    '/home/chr1s/src/oxide/oxide/objdir/out/imports'
    '/usr/lib/x86_64-linux-gnu/qt5/qml'
  Plugin paths:
    '.'

FAIL! : qml-core-test::tst_CustomURLSchemes::compile() ".allowedExtraUrlSchemes" is not available due to component versioning.
Loc: [/home/chr1s/src/oxide/oxide/qt/tests/qmltests/core/tst_CustomURLSchemes.qml(11)]

After scratching my head for a while, I can't see what I'm doing wrong here.

If I run the following simple QML app, I can access the property correctly:

- test.qml:

import QtQuick 2.0
import com.canonical.Oxide 1.3

WebView {
  focus: true
  width: 960
  height: 540

url: "https://www.google.com"

  context: WebContext {
    allowedExtraUrlSchemes: []
  }
}

However, if I run this simple app instead, then it fails with the same message I see in the unit tests:

- test.qml:

import QtQuick 2.0
import com.canonical.Oxide 1.3

TestWebView {
  focus: true
  width: 960
  height: 540

url: "https://www.google.com"

context.allowedExtraUrlSchemes: []
}

- TestWebView.qml

import QtQuick 2.0
import com.canonical.Oxide 1.3

WebView {
context: WebContext {}
}

This last example works fine without a revision number on this API.

I consider this to be a blocker for being able to update Oxide OTA, as we're not able to version new API's with this bug

Upstream bug https://bugreports.qt.io/browse/QTBUG-40043 is related to this one.

See original description

Revision history for this message

Chris Coulson (chrisccoulson) wrote on 2014-11-05:

Oxide patch to version new API's in 1.3 Edit (4.2 KiB, text/plain)

Revision history for this message

Chris Coulson (chrisccoulson) wrote on 2014-11-05:

This sounds similar to https://bugreports.qt-project.org/browse/QTBUG-40043

description:

updated

Chris Coulson (chrisccoulson) on 2014-11-05

description:

updated

Revision history for this message

Cris Dywan (kalikiana) wrote on 2014-11-06:

I notice

+ qmlRegisterType<OxideQQuickWebContext, 1>(uri, 1, 3, "WebContext");

the template argument passing the revision there - in the UITK we have versioning but we don't use that one. Also, shouldn't it be 3?

Revision history for this message

Chris Coulson (chrisccoulson) wrote on 2014-11-06:

Not exactly - the "1" matches the revision number specified in the metadata in the class declarations. Eg,

--- qt/quick/api/oxideqquickwebcontext_p.h 2014-10-09 20:22:21 +0000
+++ qt/quick/api/oxideqquickwebcontext_p.h 2014-11-05 00:22:04 +0000
@@ -60,9 +60,9 @@

Q_PROPERTY(OxideQQuickCookieManager* cookieManager READ cookieManager CONSTANT)

- Q_PROPERTY(QStringList hostMappingRules READ hostMappingRules WRITE setHostMappingRules NOTIFY hostMappingRulesChanged)
+ Q_PROPERTY(QStringList hostMappingRules READ hostMappingRules WRITE setHostMappingRules NOTIFY hostMappingRulesChanged REVISION 1)

- Q_PROPERTY(QStringList allowedExtraUrlSchemes READ allowedExtraUrlSchemes WRITE setAllowedExtraUrlSchemes NOTIFY allowedExtraUrlSchemesChanged)
+ Q_PROPERTY(QStringList allowedExtraUrlSchemes READ allowedExtraUrlSchemes WRITE setAllowedExtraUrlSchemes NOTIFY allowedExtraUrlSchemesChanged REVISION 1)

   Q_ENUMS(CookiePolicy)
   Q_ENUMS(SessionCookieMode)
@@ -164,8 +164,8 @@
   void devtoolsEnabledChanged();
   void devtoolsPortChanged();
   void devtoolsBindIpChanged();
- void hostMappingRulesChanged();
- void allowedExtraUrlSchemesChanged();
+ Q_REVISION(1) void hostMappingRulesChanged();
+ Q_REVISION(1) void allowedExtraUrlSchemesChanged();

private:
Q_PRIVATE_SLOT(d_func(), void userScriptUpdated());

Revision history for this message

Zsombor Egri (zsombi) wrote on 2015-03-30:

Actually we have revisions and we use the same declaration for components in UI Toolkit as well. And the revisioning of ViewItems attached properties are also broken, see https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/listitem-expansion/+merge/254375, where I had to do an ugly workaround to get the revisioned API accepted in Expansion.qml test code.

Changed in qtdeclarative-opensource-src (Ubuntu):
importance:	Undecided → High

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-30:

Could you bring the problem to upstream's attention via https://bugreports.qt.io/ ? I tried to search for existing similar bug reports but didn't find one. Possibly some better keyword would help in searching though.

Revision history for this message

Zsombor Egri (zsombi) wrote on 2015-03-30:

+Chris, so to give more help, the workaround:
1) create a new class which derives from the one you want to expose the revisioned API
2) move all your revisioned API into this one
3) register the new class to the version you need with the same name as in the previous version

From the upstream bug it looks like everything registered with qmlRegisterUncreatableType<type_name, revision>() breaks the versioning. We need to keep this workaround till the bug is fixed.

Revision history for this message

Zsombor Egri (zsombi) wrote on 2015-03-30:

+Timo, the bug is in Chris' comment #2. I'll add to the description.

description:

updated

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2015-03-30:

Thanks, /me blind and blaming DST. Thanks for commenting more on the upstream report, maybe it gets a bit of visibility.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2015-09-07:

#10

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in qtdeclarative-opensource-src (Ubuntu):
status:	New → Confirmed

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2016-02-01:

#11

https://codereview.qt-project.org/#/c/146588/ is now merged to Qt 5.6.

Revision history for this message

Timo Jyrinki (timo-jyrinki) wrote on 2016-02-17:

#12

More related bugs:
https://bugreports.qt.io/browse/QTBUG-50990
https://bugreports.qt.io/browse/QTBUG-48966

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Bug attachments

Oxide patch to version new API's in 1.3 Edit

Add attachment

Remote bug watches

Bug watches keep track of this bug in other bug trackers.

Ubuntuqtdeclarative-opensource-src package

API versioning broken in some cases

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
qtdeclarative-opensource-src package