Setup.exec() for existing account type results in blank full screen window

Bug #1594944 reported by dobey
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Fix Released
High
David Barth
webapps-sprint
Fix Released
Critical
Alberto Mardegan
ubuntu-system-settings-online-accounts (Ubuntu)
Fix Released
Critical
Alberto Mardegan

Bug Description

If an account already exists, calling Setup.exec() again results in a blank window being overlaid on top of the application which made the request. There is no way to close this window.

This API is what the online accounts integration in the scopes API relies upon, to allow logging in to accounts, and so we have come to rely upon this API as well in multiple places, as a means to log into the Ubuntu One account, when it is necessary to do so. However, due to this issue, the only way to reliably present a login window at an appropriate time, is to delete the account when it appears to have been invalidated by the server, and to then present the login window to create a new account.

Related branches

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

Hi Rodney, can you please provide steps on how to reproduce this?

Additionally, it would be great if you could paste the output of

    OAU_LOGGING_LEVEL=2 OAU_DAEMON_TIMEOUT=9999 online-accounts-service

while reproducing this bug.

Changed in ubuntu-system-settings-online-accounts (Ubuntu):
status: New → Incomplete
Revision history for this message
dobey (dobey) wrote :
Download full text (3.9 KiB)

Add a twitter account, and then run this attached QML on the phone. If you don't have a twitter account to test with, add any other account via system settings, and modify this QML to use that account instead of twitter. The result when the app runs is that a full screen blank window will be opened overlaid on the app itself.

Run with "qmlscene --desktop_file_hint=/usr/share/applications/dialer-app.desktop twitter-test.qml"

Output of online-account-service debug:

service.cpp 42 requestAccess Got request: QMap(("application", QVariant(QString, "com.ubuntu.developer.webapps.webapp-twitter") ) ( "pid" , QVariant(uint, 28963) ) ( "provider" , QVariant(QString, "twitter") ) )
utils.cpp 49 apparmorProfileOfPeer App ID: "unconfined"
request-manager.cpp 113 runQueue Head: OnlineAccountsUi::Request(0x1f10c78)
mir-helper.cpp 151 session_event_callback Prompt Session state updated to 1
Loading module: 'libubuntu_application_api_touch_mirclient.so.3.0.0'
/usr/bin/online-accounts-ui: unrecognized option '--socket'
/usr/bin/online-accounts-ui: unrecognized option '--profile'
ui-server.cpp 103 onDataReady QMap(("code", QVariant(QString, "process") ) ( "data" , QVariant(QVariantMap, QMap(("application", QVariant(QString, "com.ubuntu.developer.webapps.webapp-twitter") ) ( "pid" , QVariant(uint, 28963) ) ( "provider" , QVariant(QString, "twitter") ) ) ) ) ( "id" , QVariant(int, 0) ) ( "interface" , QVariant(QString, "com.ubuntu.OnlineAccountsUi") ) ( "profile" , QVariant(QString, "unconfined") ) )

(process:28975): accounts-glib-CRITICAL **: ag_application_get_desktop_app_info: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_desktop_app_info: assertion 'self != NULL' failed
file not found: "/home/phablet/.local/share/accounts/applications/.application"

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL **: ag_application_get_service_usage: assertion 'self != NULL' failed

(process:28975): accounts-glib-CRITICAL *...

Read more...

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

Argh, that's a regression I introduced fixing bug 1582824. It was a typo, fix is coming soon. :-)

Just to understand the severity of this, is this something that you can reproduce with other apps, like pay-ui? Actual webapps are not affected by this -- this only affects unconfined apps.

Changed in ubuntu-system-settings-online-accounts (Ubuntu):
status: Incomplete → In Progress
importance: Undecided → Critical
assignee: nobody → Alberto Mardegan (mardy)
Changed in webapps-sprint:
status: New → In Progress
importance: Undecided → Critical
assignee: nobody → Alberto Mardegan (mardy)
milestone: none → sprint-24
Revision history for this message
dobey (dobey) wrote :

Yes, it prevents pay-ui from working correctly. It could also affect any app in the store that uses online-accounts (but webapps have a hack that make it improbable that they would hit this issue).

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

Rodney, can you please send me the logs for the pay-ui case?

I cannot reproduce this bug with the test case you gave me: indeed, there is a blank window, but that's the twitter-test application :-)
If I add a red rectangle to it, I can definitely see it.

The attached branch is still a good thing to have, because there's obviously a typo in the code.

Changed in ubuntu-system-settings-online-accounts (Ubuntu):
status: In Progress → Incomplete
Revision history for this message
Alberto Mardegan (mardy) wrote :

No need for the logs for the pay-ui case: I installed the silo and managed to reproduce the issue. Here are the steps I used:

1) Create a U1 account
2) Open the click scope (make sure that Cut the Rope is in the results set)
3) go to login.ubuntu.com and delete the authorization
4) try to install Cut the Rope

However, there's something very strange about it: I could reproduce it only once! Now that I try to reproduce it again (by repeating steps 3 and 4), the payment seems to proceed (without me entering any password!), and when I visit login.ubuntu.com I see that the U1 token has been automatically re-added.
I tried with killing the scope, pay-service-2 (signond and its plugins automatically quit after a few seconds of inactivity), but still the token gets automatically reauthorized every time. How is it possible? I verified that the password is not stored in the signond DB. Is the password being kept in memory by some other process?

Changed in canonical-devices-system-image:
status: New → In Progress
milestone: none → 13
importance: Undecided → Critical
importance: Critical → High
Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

Any update on this issue?

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

No updates, I was waiting for some feedback on the attached branch. I've now put that into https://requests.ci-train.ubuntu.com/#/ticket/1962
Let's see how it goes.

Changed in canonical-devices-system-image:
assignee: nobody → David Barth (dbarth)
milestone: 13 → backlog
Revision history for this message
dobey (dobey) wrote :

I don't think there is currently any reasonable way to verify this bug, nor that this fix necessarily fixes the core issue. I was only able to recreate this issue when using the branches to attempt to avoid deleting the U1 token at all (which, I've since come to realize is basically impossible to avoid at this point), and when I attempted to use the proposed fix, instead of a blank window, I simply got no window, because online-accounts would not open the account plug-in to log in again, if the account already exists.

While the code being fixed here may have been wrong, I don't think it will give the desired result. Even with this fix, one must still delete the account in order to get the login window to be displayed.

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

Yes Rodney, no window will be created here. Given that an account already exists, and that U1 (along with facebook) does not allow more than one account to be created on a device, that's the correct behaviour.

Changed in ubuntu-system-settings-online-accounts (Ubuntu):
status: Incomplete → In Progress
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-system-settings-online-accounts - 0.7+16.10.20160929-0ubuntu1

---------------
ubuntu-system-settings-online-accounts (0.7+16.10.20160929-0ubuntu1) yakkety; urgency=medium

  * Properly handle early termination of account access requests (LP:
    #1594944)

 -- Alberto Mardegan <email address hidden> Thu, 29 Sep 2016 09:08:00 +0000

Changed in ubuntu-system-settings-online-accounts (Ubuntu):
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
milestone: backlog → 14
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
Alberto Mardegan (mardy)
Changed in webapps-sprint:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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