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

Bug #1305128 reported by Ken VanDine on 2014-04-09
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
content-hub
Fix Released
Undecided
Unassigned
unity-mir
Critical
Gerry Boland
unity-mir (Ubuntu)
Undecided
Unassigned
unity8 (Ubuntu)
Critical
Gerry Boland

Bug Description

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.

Related branches

Gerry Boland (gerboland) on 2014-04-10
Changed in unity8 (Ubuntu):
status: New → Confirmed
Changed in unity8:
status: New → Confirmed
importance: Undecided → Critical
assignee: nobody → Gerry Boland (gerboland)
Alberto Mardegan (mardy) wrote :

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) wrote :

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

Changed in unity-mir (Ubuntu):
status: New → Confirmed
Gerry Boland (gerboland) wrote :

@mardy - understood, will do.

Gerry Boland (gerboland) wrote :

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) wrote :

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

Bill Filler (bfiller) wrote :

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) wrote :

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) wrote :

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

Michał Sawicz (saviq) on 2014-04-15
Changed in unity8:
status: Confirmed → In Progress
Gerry Boland (gerboland) wrote :

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.

Gerry Boland (gerboland) on 2014-05-06
Changed in unity-mir:
status: New → In Progress
importance: Undecided → Critical
assignee: nobody → Gerry Boland (gerboland)
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in unity-mir:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in unity-mir (Ubuntu):
status: Confirmed → Fix Released
Michał Sawicz (saviq) wrote :

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

Changed in unity-mir:
status: Fix Committed → Fix Released
Changed in unity8:
status: In Progress → Won't Fix
Changed in unity8 (Ubuntu):
status: Confirmed → Invalid
Changed in unity8:
status: Won't Fix → Invalid
Bill Filler (bfiller) on 2014-05-30
Changed in content-hub:
status: New → Fix Released
Michał Sawicz (saviq) on 2017-03-13
Changed in unity8 (Ubuntu):
assignee: nobody → Gerry Boland (gerboland)
importance: Undecided → Critical
no longer affects: unity8
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers