ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxxxxx>]

On Tue, 2014-04-08 at 10:10 +1200, Thomi Richards wrote:

> On Tue, Apr 8, 2014 at 9:50 AM, Leo Arias <leo.arias@xxxxxxxxxxxxx>
> wrote:
> 
>                 > (Bill)
>                 >
>                 https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1297900
>                 > -> seems to only impact on tests, when the
>                 application isn't started
>                 > by upstart. Bounced between unity8, then QA who
>                 unassigned themselves.
>                 > So, seems back on Bill's plate.
>                 
>                 
>                 boiko has worked on this one, with a branch here
>                 https://code.launchpad.net/~boiko/dialer-app/autopilot_upstart, but
>                 found an issue that he's working on with Leo to
>                 resolve.
>                 
>         
>         
>         Actually this one will keep bouncing for a while. We'll
>         probably need help from upstart, unity and autopilot. 
>         
>         I'll try to make a summary of what we found last week:
>         
>         
>         Autopilot is starting the app with
>         UpstartAppLaunch.start_application_test, and it's stopping it
>         with stop_application, which sounds correct.
>         
>         This works with no issues on normal tests. But for the dialer
>         app we have a test that opens the messaging app, and that one
>         leaves the dialer app on a state that can't be started again
>         with UpstartAppLaunch.start_application_test making all the
>         following tests to fail.
>         
>         
>         
>         
>         With tedg's help we found that this is expected behavior.
>         What's different from the cases where no secondary apps are
>         started is that in this case, the dialer is left on unity's
>         recent apps category with no running process associated. If I
>         click it there, unity restarts the app. But autopilot doesn't
>         seem to be able to restart it.
>         
>         
>         I might be making a mess here, because I didn't understand all
>         the details of upstart, unity and the restartable app with no
>         process. I'm adding thomi, tedg and saviq to see if we can
>         find a solution. What's calling unity to restart that
>         application? Maybe we can call the same thing from autopilot.
>         Or maybe we can start the app in a way that doesn't leave it
>         on the recent category.
> 
> 
> 
> 
> Since we already have a special method in libUAL
> (start_application_test, as opposed to start_application), it would be
> nice if the logic for starting apps in this special state could live
> in libUAL, for a few reasons.
> 
> First, the obvious and selfish one: I'd rather not do the work :P
> 
> The second, and more reasonable reason is that I'd like to avoid tying
> autopilot to unity8 so closely, especially when upstart is available
> on the desktop today, but unity8 is not.
> 
> Having said that, if someone tells me what needs to happen in
> autopilot, I'm happy to add it ASAP.


I think that the issue isn't with start but with stop. Autopilot is
calling stop and expecting the app to be stopped after that call
returns. Where what it does is request a shutdown, and then the stopped
signal comes when the application is completely removed. This makes
sense for the shell where it doesn't want to block on stopping an app,
but perhaps not as good for autopilot in cases where it is stopping and
starting apps quickly.

So I think we could introduce a function that is something like
stop_sync() or you guys could make that part of the autopilot flow. I
think that autopilot will be the only user, but I'm fine putting it in
either location if blocking is okay for you.

Ted

Attachment: signature.asc
Description: This is a digitally signed message part