Apps don't always get focused when started with upstart-app-launch

[Ken VanDine]

We initially found this bug during content picking using content-hub, which uses upstart-app-launch to start apps that are needed. I've managed to reproduce it outside of content-hub by using upstart-app-launch. I've reproduced this with image 283

Steps to reproduce:

 upstart-app-launch com.ubuntu.gallery_gallery_2.9.1.941
 upstart-app-stop com.ubuntu.gallery_gallery_2.9.1.941

Now focus an existing running app, then

 upstart-app-launch com.ubuntu.gallery_gallery_2.9.1.941

This should start gallery and focus it, instead it starts gallery without giving it focus.

[Alberto Mardegan (mardy)]

I'm not sure whether this is related, but Saviq asked me to add a comment in here about my issue: when an application quits, the view goes back to the Apps scope, and not to the previously opened application.
You can verify what this means by creating a Google or Facebook account from the System settings: as soon as the authentication window disappears, you'll be taken back to the Apps scope and not to the Online Accounts window.

This will be fully fixed when we implement trusted sessions, but it would be nice if meanwhile we can make the experience of creating an account a bit better. :-)

[Launchpad Janitor (janitor)]

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

[Gerry Boland (gerboland)]

@mardy - understood, will do.

[Gerry Boland (gerboland)]

Just tried testing this on today's image (294) and it works fine. The app launched via UAL is brought to the front and focused. Am I missing something?

[Alberto Mardegan (mardy)]

Forget about comment #1: this has been separately reported as bug 1307440.

[Bill Filler (bfiller)]

It's still broken for me in 294.

Simple test:
1) launch address-book
2) create a contact
3) click the widget to choose avatar for the contact
4) gallery will get launched
5) press cancel in the gallery
6) you are returned to address book
7) press widget to choose avatar again

Expected results:
should be brought back to gallery

Actual results:
Screen says "loading" and never brought back to gallery

[Ken VanDine (ken-vandine)]

I can still reproduce this with the upstart-app-launch with the steps in the description. Also of note, after stopping gallery with upstart-app-launch, it still appears as running in the shell.

[Ken VanDine (ken-vandine)]

Previous comment should have said "after stopping gallery with upstart-app-stop".

[Gerry Boland (gerboland)]

Sorry I dropped the ball on this bug. Resuming right now. It appears that shell never registered that gallery quit, and rejects a new instance of gallery starting.

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:unity-mir/devel at revision 222, scheduled for release in unity-mir, milestone Unknown

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-mir - 0.4+14.10.20140520-0ubuntu1

---------------
unity-mir (0.4+14.10.20140520-0ubuntu1) utopic; urgency=low

  [ Tarmac ]
  * Merge devel at rev 222. (Fix crash on shell shutdown; Refactor app
    shutdown) 2014-05-06 Gerry Boland <email address hidden>
            [220] Fix crash on Mir-initiated shutdown, where stop() was
    being         called on an already shutting-down server.         Mir
    initiates shutdown on SIGINT & SIGTERM, need to distinguish that
            shutdown from a client-initiated shutdown. Do this by
    installing a         custom signal handler that is run after Mir's
    initiate-shutdown         handler is called, so that we only call
    server.stop() on a client-         initiated shutdown. (LP:
    #1305128, #1315251)

  [ Kevin Gunn ]
  * Merge devel at rev 222. (Fix crash on shell shutdown; Refactor app
    shutdown) 2014-05-06 Gerry Boland <email address hidden>
            [220] Fix crash on Mir-initiated shutdown, where stop() was
    being         called on an already shutting-down server.         Mir
    initiates shutdown on SIGINT & SIGTERM, need to distinguish that
            shutdown from a client-initiated shutdown. Do this by
    installing a         custom signal handler that is run after Mir's
    initiate-shutdown         handler is called, so that we only call
    server.stop() on a client-         initiated shutdown. (LP:
    #1305128, #1315251)
 -- Ubuntu daily release <email address hidden> Tue, 20 May 2014 12:58:36 +0000

[Michał Sawicz (saviq)]

I believe the content-hub task here can be closed?