Switching windows with a Trusted Prompt Session active loses the trusted prompt session

Bug #1355173 reported by Ted Gould on 2014-08-11
82
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Critical
Unassigned
Mir
Fix Released
Undecided
Nick Dedekind
0.8
Fix Released
Undecided
Mir development team
Online Accounts setup for Ubuntu Touch
Critical
Alberto Mardegan
mir (Ubuntu)
Undecided
Unassigned
mir (Ubuntu RTM)
Undecided
Cemil Azizoglu
pay-service (Ubuntu)
Undecided
Unassigned
qtmir (Ubuntu)
Critical
Nick Dedekind
qtmir (Ubuntu RTM)
Critical
Michał Sawicz
trust-store (Ubuntu)
Undecided
Unassigned
ubuntu-system-settings-online-accounts (Ubuntu)
High
Alberto Mardegan

Bug Description

When we create a trusted prompt session over an application, let's say a small dialog, and then switch applications, when we switch back to the original application the dialog is not overlayed on top of the original application. The program providing the dialog seems happy, and is still running, but visually it is not there.

We notice this when using the payments UI which overlays ontop of the dash. In some cases we need to show Online Accounts which runs as an independent application and causes a switching behavior. When returning back to the dash the Payment UI is not visible. It also happens if the Payment UI is visible and you switch applications using the right swipe.

Related branches

Ted Gould (ted) on 2014-08-11
tags: added: rtm14
Changed in qtmir:
importance: Undecided → Critical
Gerry Boland (gerboland) wrote :

By design, if you switch applications, the trust session is supposed to close. So if you switch away from an app using a trust helper, or you switch back to the Dash, in both cases the trust helper should be closed. The application should know this though.

On Wed, 2014-08-13 at 23:10 +0000, Gerry Boland wrote:

> By design, if you switch applications, the trust session is supposed to
> close. So if you switch away from an app using a trust helper, or you
> switch back to the Dash, in both cases the trust helper should be
> closed. The application should know this though.

I don't think that works unfortunately today. For instance, we need to
show Online Accounts (which won't be a trusted prompt session for
RTM :-( ) and we can't have that hide the Pay UI. I think that the
trusted prompt helper should remain attached to the application even
when switching, at least until we get everything converted to use the
proper APIs.

Changed in qtmir:
assignee: nobody → Michael Zanetti (mzanetti)

Some concrete steps to reproduce the issue would help getting this bug fixed faster. For instance: I've no idea how to summon the payments dialog on top of the dash

Ted Gould (ted) wrote :

There are a set of scripts that convert a device over to using staging, and then you can purchase one of the applications there. That process is documented as part of the test plan.

https://wiki.ubuntu.com/Process/Merges/TestPlan/pay-service

Michael Zanetti (mzanetti) wrote :

So seems this behavior of trusted prompt sessions is the expected one. The issue happens because UOA is not using trusted prompt sessions yet. Added that component to this bug.

Michael Zanetti (mzanetti) wrote :

In case UOA can't be fixed in time for whatever reason, the attached branch of qtmir would work around the issue at the cost of breaking another use case.

Changed in qtmir:
status: New → Invalid
Changed in ubuntu-system-settings-online-accounts:
importance: Undecided → Critical
status: New → Confirmed
Michał Sawicz (saviq) on 2014-08-15
summary: - Switching windows with a Trusted Prompt Session active looses the
- trusted prompt session
+ Switching windows with a Trusted Prompt Session active loses the trusted
+ prompt session
Michał Sawicz (saviq) wrote :

> By design, if you switch applications, the trust session is supposed to
> close. So if you switch away from an app using a trust helper, or you
> switch back to the Dash, in both cases the trust helper should be
> closed. The application should know this though.

Is this really true? I believe we were supposed to just keep the prompt with the app and let it live? With the exception of a few sensitive helpers (like payments)?

Alejandro J. Cura (alecu) wrote :

Even in the case of payments the prompt must not be hidden by the system, because the user may have switched while doing the payment to a password manager or a second factor authentication app.
In any case, the payment UI should set a timeout to close for security reasons, but I don't think we want this to be the system policy.

Michał Sawicz (saviq) wrote :

Oh yeah, definitely, it'd be the prompt's responsibility to time out and close (or display a timed-out message or so).

The prompt just gets an unfocus event, to do with at its own leisure.

Nick Dedekind (nick-dedekind) wrote :

This was a condition enforced in the first iteration of prompt sessions. It will be removed later, once the services support parallel processing of prompt requests.

The payments helper should be putting password prompts/etc as part of it's prompt providers, as far as I'm aware, there shouldn't need to be any app context switching when dealing with prompt sessions.

On Fri, 2014-08-15 at 14:43 +0000, Nick Dedekind wrote:

> This was a condition enforced in the first iteration of prompt sessions.
> It will be removed later, once the services support parallel processing
> of prompt requests.

We do this today. Which is, ironically, the only way it works as the
user can click the pay button again and we do a second prompt :-)

> The payments helper should be putting password prompts/etc as part of
> it's prompt providers, as far as I'm aware, there shouldn't need to be
> any app context switching when dealing with prompt sessions.

There would be if you had something like a password manager and you
needed to go look up the password and come back to the dialog. Or
perhaps for 2fa you'd go to authenticator.

Michał Sawicz (saviq) wrote :

Nick, alecu was saying about the case where you use a password manager of some sort and need to check it for the password you've been asked for in the prompt.

Even if we have such a limitation, it should be enforced when a new prompt is opened, not when you unfocus the original one.

David Barth (dbarth) wrote :

Online Accounts is now getting support for the Trust Session Prompts. It is landing in Utopic as I speak.

Michał Sawicz (saviq) wrote :

\o/

Ted Gould (ted) on 2014-08-19
Changed in ubuntu-system-settings-online-accounts:
status: Confirmed → Fix Released
Michał Sawicz (saviq) on 2014-09-04
Changed in qtmir:
status: Invalid → Triaged
importance: Critical → High
assignee: Michael Zanetti (mzanetti) → nobody
Changed in unity8 (Ubuntu):
status: New → Triaged
importance: Undecided → High
Michał Sawicz (saviq) wrote :

I'm reopening this for QtMir and Unity8 as this is still an issue. A smaller now that we have UOA working as a trusted prompt, but still we should not close the trusted prompts on unfocus.

I believe we should leave the prompt "management" to the trusted helper. It's the only one that can know if, and when, its prompt should be closed without user interaction. It might be a timeout (as is suggested for payments), or it could very well live forever.

Maybe we need a flag on a prompt that would define the behaviour? I.e. if a trusted helper is in its early days it'd be closed on unfocus because it can't handle multiple sessions at the same time, but if the helper can handle it by itself, it would say so starting the prompt and we'd let it manage its sessions.

We might need to handle the transitions if a prompt times out when in spread, for example, but that's visual polish.

David Barth (dbarth) on 2014-09-05
tags: added: touch-2014-09-11
David Barth (dbarth) on 2014-09-05
Changed in ubuntu-system-settings-online-accounts:
assignee: nobody → Alberto Mardegan (mardy)
tags: removed: touch-2014-09-11
kevin gunn (kgunn72) on 2014-09-08
tags: added: touch-2014-10-30
David Barth (dbarth) on 2014-09-09
Changed in ubuntu-system-settings-online-accounts:
status: Fix Released → Fix Committed
kevin gunn (kgunn72) on 2014-09-10
Changed in qtmir:
assignee: nobody → Nick Dedekind (nick-dedekind)
Changed in unity8 (Ubuntu):
assignee: nobody → Nick Dedekind (nick-dedekind)
Launchpad Janitor (janitor) wrote :

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

Changed in ubuntu-system-settings-online-accounts (Ubuntu):
status: New → Confirmed
David Barth (dbarth) on 2014-09-16
Changed in ubuntu-system-settings-online-accounts:
status: Fix Committed → Fix Released
Changed in ubuntu-system-settings-online-accounts (Ubuntu):
status: Confirmed → Fix Released
dobey (dobey) wrote :

This is somewhat important for the purchase flow, as the screen may blank while the user is distracted, or user may need to switch away to LastPass or two factor auth app to continue the process, which will currently interrupt the process.

David Barth (dbarth) on 2014-09-30
Changed in ubuntu-system-settings-online-accounts (Ubuntu):
assignee: nobody → Alberto Mardegan (mardy)
importance: Undecided → High
Selene Scriven (toykeeper) wrote :

This appears to work in rtm krillin 112.

Selene Scriven (toykeeper) wrote :

Actually, nevermind... it doesn't happen after the account has been successfully auth'd, but the issue is about it failing before that point. I misunderstood.

Ken VanDine (ken-vandine) wrote :

This will be important for content-hub transfers as well, which we'll be starting on soon.

kevin gunn (kgunn72) on 2014-10-23
Changed in unity8 (Ubuntu):
importance: High → Critical
Changed in qtmir:
importance: High → Critical
Michał Sawicz (saviq) on 2014-10-23
Changed in ubuntu-system-settings-online-accounts:
status: Fix Released → Confirmed
Changed in ubuntu-system-settings-online-accounts (Ubuntu):
status: Fix Released → Confirmed
Michał Sawicz (saviq) wrote :

Adding tasks for all the affected parties: to fix this, we will not terminate the trusted sessions on unfocus any more. Your trusted helper needs to decide what to do (do nothing, close, close after a timeout, close when another session opened etc.).

Caveat is that we need to make sure it's clear whether it's unfocused because the whole application got unfocused, or because there was another prompt open on top (an idea is to use the active property of the app).

Note that we also have bug #1384950 in store for the future, when trusted helpers will have to adjust behaviour as well.

Changed in qtmir:
status: Triaged → In Progress
kevin gunn (kgunn72) on 2014-10-27
Changed in unity8 (Ubuntu RTM):
assignee: nobody → Nick Dedekind (nick-dedekind)
status: New → In Progress
importance: Undecided → Critical
status: In Progress → Triaged
David Barth (dbarth) wrote :

I'm proposing to group all related branches in the same silo to verify that the fixes resolve the use case issue we had, namely: I can't create an account with 2FA, since I can't switch away from the trust prompt.

Let me know if you want me to request a silo once branches get ready.

Changed in unity8 (Ubuntu):
importance: Critical → High
Alberto Mardegan (mardy) wrote :

After further inspection of the code, I believe that no change in needed in ubuntu-system-settings-online-accounts: the current code just quits the session when the session state changes to "mir_prompt_session_state_stopped", which should be correct even with the new changes.

Changed in ubuntu-system-settings-online-accounts:
status: Confirmed → Invalid
Changed in ubuntu-system-settings-online-accounts (Ubuntu):
status: Confirmed → Invalid
Olli Ries (ories) wrote :

this bug needs to be targeted after RTM, via ota

tags: added: ota-1
removed: touch-2014-10-30
kevin gunn (kgunn72) on 2014-11-06
Changed in qtmir (Ubuntu RTM):
assignee: nobody → Nick Dedekind (nick-dedekind)
Changed in qtmir (Ubuntu):
assignee: nobody → Nick Dedekind (nick-dedekind)
Changed in qtmir (Ubuntu RTM):
importance: Undecided → Critical
Changed in qtmir (Ubuntu):
importance: Undecided → Critical
Changed in mir:
assignee: nobody → Nick Dedekind (nick-dedekind)
milestone: none → 0.10.0
status: New → In Progress
Launchpad Janitor (janitor) wrote :

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

Changed in pay-service (Ubuntu):
status: New → Confirmed
Changed in qtmir (Ubuntu):
status: New → Confirmed
Changed in trust-store (Ubuntu):
status: New → Confirmed
kevin gunn (kgunn72) on 2014-11-21
Changed in unity8 (Ubuntu):
status: Triaged → In Progress
Changed in canonical-devices-system-image:
importance: Undecided → Critical
milestone: none → ww51-2014
status: New → Confirmed
kevin gunn (kgunn72) on 2014-12-02
Changed in unity8 (Ubuntu):
importance: High → Critical
Michał Sawicz (saviq) on 2014-12-05
Changed in unity8 (Ubuntu RTM):
assignee: Nick Dedekind (nick-dedekind) → nobody
milestone: none → 14.09-ota-1
Changed in qtmir (Ubuntu RTM):
assignee: Nick Dedekind (nick-dedekind) → nobody
milestone: none → 14.09-ota-1
status: New → Triaged
Changed in qtmir (Ubuntu):
status: Confirmed → Triaged
status: Triaged → In Progress
Michał Sawicz (saviq) wrote :

Let's target this for ww03-2015.

Changed in canonical-devices-system-image:
status: Confirmed → New
Changed in qtmir (Ubuntu RTM):
milestone: 14.09-ota-1 → none
Changed in unity8 (Ubuntu RTM):
milestone: 14.09-ota-1 → none
Changed in canonical-devices-system-image:
milestone: ww51-2014 → ww03-2015
status: New → Confirmed
Bill Filler (bfiller) on 2014-12-17
Changed in canonical-devices-system-image:
status: Confirmed → In Progress
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.10.0

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
milestone: 0.10.0 → none
status: Fix Committed → Fix Released
milestone: none → 0.10.0
Daniel van Vugt (vanvugt) wrote :

mir (0.10.0+15.04.20150107.2-0ubuntu1) vivid; urgency=medium

Changed in mir (Ubuntu):
status: New → Fix Released
Michał Sawicz (saviq) on 2015-01-09
Changed in qtmir (Ubuntu RTM):
assignee: nobody → Michał Sawicz (saviq)
Changed in unity8 (Ubuntu RTM):
assignee: nobody → Michał Sawicz (saviq)
Michał Sawicz (saviq) on 2015-01-09
no longer affects: unity8 (Ubuntu)
no longer affects: unity8 (Ubuntu RTM)
Changed in mir (Ubuntu RTM):
assignee: nobody → Cemil Azizoglu (cemil-azizoglu)
status: New → Triaged
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtmir - 0.4.4+15.04.20150109-0ubuntu1

---------------
qtmir (0.4.4+15.04.20150109-0ubuntu1) vivid; urgency=low

  [ Ubuntu daily release ]
  * New rebuild forced

  [ Nick Dedekind ]
  * Notify prompt sessions that sessions have been suspended/resumed.
    (LP: #1355173, #1384950)
 -- Ubuntu daily release <email address hidden> Fri, 09 Jan 2015 17:26:00 +0000

Changed in qtmir (Ubuntu):
status: In Progress → Fix Released
Michał Sawicz (saviq) on 2015-01-13
Changed in qtmir (Ubuntu RTM):
milestone: none → 14.09-ota-2
status: Triaged → In Progress
Changed in mir (Ubuntu RTM):
milestone: none → 14.09-ota-2
status: Triaged → In Progress
Launchpad Janitor (janitor) wrote :
Download full text (11.9 KiB)

This bug was fixed in the package mir - 0.8.1+15.04.20150112.2~rtm-0ubuntu1

---------------
mir (0.8.1+15.04.20150112.2~rtm-0ubuntu1) 14.09; urgency=medium

  [ Daniel van Vugt ]
  * Bug fix release 0.8.1 (https://launchpad.net/mir/+milestone/0.8.1)
    - ABI summary: Servers need rebuilding, but clients do not;
      . Mirclient ABI unchanged at 8
      . Mircommon ABI unchanged at 2
      . Mirplatform ABI unchanged to 3
      . Mirserver ABI bumped to 26.1 (due to breakage in LP: #1355173)
    - Fixes bugs:
      . Switching windows with a Trusted Prompt Session active loses the
        trusted prompt session (LP: #1355173)
      . a prompt session with an invalid application pid should be an error
        (LP: #1377968)
  * mir_demo_client_basic: Don't assert on user errors like failing to
    connect to a Mir server. It's much more useful to tell the user what
    they did wrong than to automatically generate error reports and
    duplicate apport bugs. (LP: #1331958) . (LP: #1331958)
  * Enable "Project Butter" motion event resampling and prediction for a
    more responsive touch experience. .
  * When the server disconnects unexpectedly, give the client SIGHUP
    instead of the present SIGTERM. The former is more appropriate
    because it indicates: "Hangup detected on controlling terminal or
    death of controlling process" [signal(7)] whereas SIGTERM is
    reserved for more polite user-requested shutdowns. .
  * Fix the common/shared source tree layout inconsistency. If it goes
    in libmircommon then it should be called "common" and not "shared":
  * Move mir::time::*Clock out of libmirserver and into libmircommon. It
    will soon be used by libmirclient.
  * Bump version to 0.8.0 as Mir 0.7.0 was released today.
  * Remove dead code "kill_client_processes()" from mir_test_framework.
  * Work around spurious SIGKILL delivered to clients by Valgrind during
    tests. This is why CI is failing randomly (LP: #1364772) Actually
    this workaround is nothing new. A quick grep shows we already use
    the same hack in 13 other locations under tests/. . (LP: #1364772)
  * Privatise (don't install) headers that are unused by clients, QtMir
    or USC. This reduces the size of the public include/ tree from 377
    to 121 files, and reduces the number of those that get installed
    from 208 to 121.
  * Bump the mircommon ABI to 2. We actually broke it in the Mir 0.7.0
    release with symbols.map and didn't notice in time (LP: #1364890)
    (LP: #1364890)
  * Restore support for gcc-4.8/trusty (LP: #1366134) (LP: #1366134)
  * Publish an internal header that QtMir recently started using:
    mir/input/input_channel.h (LP: #1365934) . (LP: #1365934)
  * Relax dependencies on libmirplatform2. Any binary package that uses
    libmirplatform2 should already be ABI compatible with any version of
    libmirplatform2. Assuming we maintain our ABIs correctly...
    Minimising exact version requirements should minimise future package
    upgrade problems. .
  * Privatise more headers -- these are the ones unused by any external
    projects but are used internally by the server code in examples/
    only.
  * Introducing a generic client per...

Changed in mir (Ubuntu RTM):
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtmir - 0.4.4+15.04.20150112.3~rtm-0ubuntu1

---------------
qtmir (0.4.4+15.04.20150112.3~rtm-0ubuntu1) 14.09; urgency=medium

  [ Nick Dedekind ]
  * Compatibility for Mir 0.8.1
  * Notify prompt sessions that sessions have been suspended/resumed.
    (LP: #1355173, #1384950)

  [ Ricardo Salveti de Araujo ]
  * qteventfeeder: adding bt and wired headset multimedia keys (LP:
    #1398427)
 -- Ubuntu daily release <email address hidden> Mon, 12 Jan 2015 13:38:21 +0000

Changed in qtmir (Ubuntu RTM):
status: In Progress → Fix Released
Michał Sawicz (saviq) on 2015-01-14
Changed in qtmir:
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
status: In Progress → Fix Released
Michał Sawicz (saviq) on 2017-03-13
no longer affects: qtmir
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers