Comment 13 for bug 1563007

Revision history for this message
Alberto Mardegan (mardy) wrote :

I tried to reproduce the bug while keeping the following command running on the terminal:
    OAU_LOGGING_LEVEL=2 OAU_DAEMON_TIMEOUT=9999 U1_DEBUG=1 online-accounts-service

And here's the output:

===============
ui-server.cpp 103 onDataReady QMap(("code", QVariant(QString, "process") ) ( "data" , QVariant(QVariantMap, QMap(("pid", QVariant(uint, 2973) ) ( "provider" , QVariant(QString, "ubuntuone") ) ( "serviceType" , QVariant(QString, "ubuntuone") ) ( "windowId" , QVariant(uint, 2973) ) ) ) ) ( "id" , QVariant(int, 0) ) ( "interface" , QVariant(QString, "com.ubuntu.OnlineAccountsUi") ) ( "profile" , QVariant(QString, "unconfined") ) )
file not found: "/home/phablet/.local/share/accounts/applications/.application"
qml: Page_QMLTYPE_24(0xe644f0)"Ubuntu One": In Ubuntu.Components 1.3, the use of Page.title, Page.flickable and Page.head is deprecated. Use Page.header and the PageHeader component instead.
file:///home/phablet/.local/share/accounts/qml-plugins/ubuntuone/Main.qml: File not found
2016-03-30 11:37:04,179 - DEBUG - request.cpp 115 setWindow Requesting window reparenting
2016-03-30 11:37:04,180 - WARNING - QWindow::fromWinId(): platform plugin does not support foreign windows.
2016-03-30 11:37:04,556 - WARNING - Got invalid serialized mime data. Ignoring it.
2016-03-30 11:37:36,558 - DEBUG - Network::OnReply from QUrl( "https://login.ubuntu.com/api/v2/tokens/oauth" ) status: 401
2016-03-30 11:37:36,625 - DEBUG - Network::OnReply from QUrl( "https://login.ubuntu.com/api/v2/tokens/oauth" ) status: 401
2016-03-30 11:37:36,629 - CRITICAL - Error occurred creating token: 0 (Network::OnReply: empty payload, giving up.)
2016-03-30 11:38:20,984 - DEBUG - Network::OnReply from QUrl( "https://login.ubuntu.com/api/v2/tokens/oauth" ) status: 200
2016-03-30 11:38:20,990 - WARNING - OAuth token received for "Ubuntu One @ ubuntu-phablet"
2016-03-30 11:38:21,003 - DEBUG - in storeToken(): no accounts found in accountList, creating new
2016-03-30 11:38:21,008 - DEBUG - storeToken() : creating new Identity for account 0
2016-03-30 11:38:21,239 - DEBUG - in UbuntuOneCredentialsService::handleCredentialsStored
2016-03-30 11:38:21,243 - DEBUG - ====== PLUGIN FINISHED ======
2016-03-30 11:38:21,244 - DEBUG - provider-request.cpp 176 onDenied
2016-03-30 11:38:21,262 - WARNING - Attempted to deliver an event to a non-existent window, ignoring.
2016-03-30 11:38:21,262 - WARNING - Attempted to deliver an event to a non-existent window, ignoring.
2016-03-30 11:38:21,266 - DEBUG - ui-server.cpp 86 ~UiServerPrivate
ui-proxy.cpp 377 ~UiProxy
mir-helper.cpp 151 session_event_callback Prompt Session state updated to 0
QProcess: Destroyed while process ("/usr/bin/online-accounts-ui") is still running.
===============

So, in this case (and this is different from Victor's logs, so there might actually be several different issues here), the plugin correctly emits the finished() signal. However, the "onDenied" message shows that the account creation was not completed successfully.
The creation is considered to be successful if the value of "account.accountId" (where "account" is the object passed by online-accounts-ui to the plugin) is greater than 0. Looking at the code in the UbuntuOne credentials, I see that Keyring::storeToken() creates a completely new account, without using the same account object provided by online-accounts-ui. So, while an account has been successfully created, it's not the account expected by online-accounts-ui.

It's a mystery why this ever worked. I cannot see any recent changes in ubuntuone-credentials or online-accounts-ui touching this part of the code.

Anyway, about how to fix this:
1) the proper solution is to add an account property to UbuntuOneCredentialsService, which in turn propagates it to the Keyring, which should then operate on the provided account object instead of creating a new one.
2) the quick & dirty way is for the QML plugin to call account.store() before using the Keyring, so that the Keyring will pick up the freshly stored account. However, in this way we'll be left with a semi-created account in case the account plugin crashes or aborts the creation, which is likely to cause even more problems. So, I suggest not going down this road.