System Settings -> Accounts and back shows black screen and 5s delay

[Alan Pope 🍺🐧🐱 🦄]

mako image #219
Open System Settings
Tap Accounts

Note a black flash between System Settings and Accounts
Press 'Back' to go back from Accounts to System Settings

Note a black flash - and sometimes a 5 second delay before getting back to System settings.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: ubuntu-system-settings 0.1+14.04.20140228-0ubuntu1
Uname: Linux 3.4.0-4-mako armv7l
ApportVersion: 2.13.2-0ubuntu5
Architecture: armhf
Date: Tue Mar 4 14:52:38 2014
InstallationDate: Installed on 2014-03-04 (0 days ago)
InstallationMedia: Ubuntu Trusty Tahr (development branch) - armhf (20140304)
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 SHELL=/bin/bash
SourcePackage: ubuntu-system-settings
UpgradeStatus: No upgrade log present (probably fresh install)

[Alan Pope 🍺🐧🐱 🦄 (popey)]

http://youtu.be/7hbwKlIGX24 shows it.

[Launchpad Janitor (janitor)]

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

[Iain Lane (laney)]

The online accounts panel launches itself in a special way. Reassigning there.

[Alberto Mardegan (mardy)]

Looks like unity8 is crashing. Alan, can you get the pid of the shell before and after the 5 seconds delay?

[Alan Pope 🍺🐧🐱 🦄 (popey)]

Same pid for the unity8 process before, during and after switching.

Attached /home/phablet/.cache/upstart/application-legacy-ubuntu-system-settings-.log and /home/phablet/.cache/upstart/unity8.log

[Michał Sawicz (saviq)]

This is between unity8 and unity-mir, I expect, unless it's Accounts that actually takes 5s to exit.

It doesn't seem to be upstart, right? Is Accounts managed by upstart at all?

This would be solved by accounts becoming part of trusted sessions et al, but regardless it should go straight away, not after 5s.

[Alberto Mardegan (mardy)]

On 03/14/2014 11:13 PM, Michał Sawicz wrote:
> This is between unity8 and unity-mir, I expect, unless it's Accounts
> that actually takes 5s to exit.

It does. :-) That's the default timeout value for the daemon to exit
when inactive, though it can be changed with the UOA_DAEMON_TIMEOUT
environment variable.

> It doesn't seem to be upstart, right? Is Accounts managed by upstart at
> all?

No, it's managed by D-Bus: it's started via D-Bus activation when the
System Settings or another client application calls one of its methods.

> This would be solved by accounts becoming part of trusted sessions et
> al, but regardless it should go straight away, not after 5s.

We can argue whether this 5 seconds timeout makes sense, I've just been
used to this practice (it's also used in many other daemons, for example
in Telepathy).
However, it's wrong to expect that the online-accounts-ui process will
quit when you close its window in the System Settings: there might be
another application which is talking to it at the same time, and this
should keep the process alive.

Anyway, yes, I also think that all this will be fixed when we start
using trusted sessions.

[Michał Sawicz (saviq)]

On 17.03.2014 09:00, Alberto Mardegan wrote:
> On 03/14/2014 11:13 PM, Michał Sawicz wrote:
>> This is between unity8 and unity-mir, I expect, unless it's Accounts
>> that actually takes 5s to exit.
>
> It does. :-) That's the default timeout value for the daemon to exit
> when inactive, though it can be changed with the UOA_DAEMON_TIMEOUT
> environment variable.

--8<--

>> This would be solved by accounts becoming part of trusted sessions et
>> al, but regardless it should go straight away, not after 5s.
>
> We can argue whether this 5 seconds timeout makes sense, I've just been
> used to this practice (it's also used in many other daemons, for example
> in Telepathy).
> However, it's wrong to expect that the online-accounts-ui process will
> quit when you close its window in the System Settings: there might be
> another application which is talking to it at the same time, and this
> should keep the process alive.

Yeah, that's all fine, the bug that we need to fix here either way is,
then, that the application is still considered running when it removed
its only surface (did it remove it?). It should go away as soon as the
surface is gone.

--
Michał (Saviq) Sawicz <email address hidden>
Canonical Services Ltd.

[Selene ToyKeeper (toykeeper)]

I tried this with music playing.

I start the settings app. Everything works fine.
I tap "Accounts", the screen slides to the right, stays white for a couple seconds, then displays the account settings app.
I tap "back", and the music player comes onscreen for about 5 seconds. Then the Apps scope appears, showing me all the apps I'm running.

It doesn't actually go back to the main settings app unless I manually select it from the apps scope.

[Gerry Boland (gerboland)]

Right now unity-mir has a one-to-one connection between a Session and a Surface (legacy design decision that we'll move away from). It has also made the assumption that focus only needs to be shifted on Session closure, not Surface. Both these combine to exhibit this problem.

Some minor refactoring of unity-mir would solve this issue.

[Selene ToyKeeper (toykeeper)]

FWIW, this is a video of what I see when triggering this bug.

[Selene ToyKeeper (toykeeper)]

Reproduced on utopic image 2.

[Selene ToyKeeper (toykeeper)]

The account settings app no longer behaves so strangely on open and close, as of image utopic 60.

[Selene ToyKeeper (toykeeper)]

Nevermind that last comment. On Utopic 166, fresh after flashing, "Accounts -> Settings -> Back" showed a black screen for about 20 seconds and then left the phone in a state where tapping "Accounts" did nothing.

The 20-second delay doesn't always happen (it seems to be a crash), but the inability to re-launch it is consistent. I assume these are probably two different bugs, but I'll attach the crash dump anyway.

[Launchpad Janitor (janitor)]

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

[David Barth (dbarth)]

I can't reproduce the long delay either.

The inability to restart OA is the same issue as Bug #1269841

[David Barth (dbarth)]

If possible can you try to upload the crash dump via ubuntu-bug to get it retraced?

[David Barth (dbarth)]

As for the long black screen on return, i'll mark it incomplete for now, since I don't know of a way to reproduce the issue anymore.

[kevin gunn (kgunn72)]

I've been testing for this bug for the last 30 minutes or so.
I believe this bug must have been corrected through some other course of events.

[David Barth (dbarth)]

It has been fixed by the refactoring of OA settings into an embedded USS plugin.