840268 - --runapp doesn't disable the lockscreen or launch the named app

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

[Jonathan Griffin (:jgriffin)]

When launching the B2G desktop build with --runapp "Test Agent", the output suggests that the lockscreen will be disabled:

--runapp found app: Test Agent, disabling lock screen...
XXX FIXME : Got a mozContentEvent: accessibility-screenreader
FTU manifest cannot be found skipping.
###################################### forms.js loaded
--runapp launching app: Test Agent

However, the lockscreen is not disabled.  The Test Agent app is launched, but behind the lockscreen so it isn't visible.

Does this matter for the gaia unit tests?

Comment 1

[Jonathan Griffin (:jgriffin)]

(In reply to Jonathan Griffin (:jgriffin) from comment #0)
> 
> However, the lockscreen is not disabled.  The Test Agent app is launched,
> but behind the lockscreen so it isn't visible.
> 
I take that part back, it doesn't seem to automatically launch the Test Agent app either, even though the dump output claims to.

Comment 2

[Jonathan Griffin (:jgriffin)]

In the context of the Gaia Unit tests in buildbot, we could get around this by using Marionette to disable the lock screen and launch the Test App.  But, that would require Marionette-enabled B2G desktop builds, and I'd rather have this work with any B2G desktop build.

Comment 3

[Jonathan Griffin (:jgriffin)]

The unlock problem occurs because the current unlock code doesn't seem to work well when unlock() is called and no app is active, as happens in http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/runapp.js.

Comment 4

[Jonathan Griffin (:jgriffin)]

This currently blocks getting Gaia Unit tests in TBPL.  I've tried working around this by writing "lockscreen.enabled": false and "lockscreen.locked": false to settings.json, but this doesn't work either.  We can't programmatically launch the Test Agent app, or disable the lockscreen, without using Marionette.  If we're OK with only running these on Marionette-enabled builds, I can proceed with that approach.

David, should I wait for this to be fixed or go ahead and require Marionette?

Comment 5

[James Lal [:lightsofapollo]]

Jonathan... I think I have a fix (requires a gecko & gaia patch so far) but marionette is probably going to make this easier in the long run no?

Comment 6

[James Lal [:lightsofapollo]]

Attachment: Update runapp observer.

Comment 7

[[:fabrice] Fabrice Desré]

Comment on attachment 719699 [details] [diff] [review]
Update runapp observer.

Review of attachment 719699 [details] [diff] [review]:
-----------------------------------------------------------------

::: CLOBBER
@@ +14,5 @@
>  #          O <-- Clobber   O  <-- Clobber
>  #
>  # Note: The description below will be part of the error message shown to users.
>  #
> +Bug 784841 pretty much changed how the build system works. It's best to clobber.

You probably don't want to clobber for this bug ;)

Comment 8

[James Lal [:lightsofapollo]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8387

Pointer to Github pull-request

Comment 9

[James Lal [:lightsofapollo]]

Attachment: Update runapp observer. ( and kill clobber from old patch oops..)

Comment 10

[[:fabrice] Fabrice Desré]

Comment on attachment 719709 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8387

I would prefer to have { } even on one line if's, but I don't know what the code style is in gaia so I let you decide that.

Comment 11

[James Lal [:lightsofapollo]]

gaia piece landed here: https://github.com/mozilla-b2g/gaia/commit/8a5b3052bb389898d5ba7bee63b71dea92139519

Note: the gaia piece is safe to land before the gecko piece they don't have interdependency.

Comment 12

[Jonathan Griffin (:jgriffin)]

(In reply to James Lal [:lightsofapollo] from comment #5)
> Jonathan... I think I have a fix (requires a gecko & gaia patch so far) but
> marionette is probably going to make this easier in the long run no?

Yes and no.  Marionette isn't enabled in all builds, and it's nice to have this functionality in builds that aren't Marionette-enabled.  In particular for running Gaia unit tests in automation, I'd rather not require Marionette just as a mechanism of launching one app, if another solution exists.

Comment 13

[Jonathan Griffin (:jgriffin)]

Is the gecko patch ready to land now?

Comment 14

[James Lal [:lightsofapollo]]

@jgriffin

This is ready... How do you plan to use this in automation? I don't think there is any signal when -runapp finishes. test-agent will attempt to connect to the socket ASAP so you could base "launched" as the point where the websocket connects.

@RyanVM

Hmm... not sure why checkin-needed was removed. The gaia patch _was_ landed but we need the gecko patch to fix this bug. It has r+ what else is needed so we can land this to inbound?

Comment 15

[Jonathan Griffin (:jgriffin)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1501761c9726

Comment 16

[Jonathan Griffin (:jgriffin)]

(In reply to James Lal [:lightsofapollo] from comment #14)
> @jgriffin
> 
> This is ready... How do you plan to use this in automation? I don't think
> there is any signal when -runapp finishes. test-agent will attempt to
> connect to the socket ASAP so you could base "launched" as the point where
> the websocket connects.
> 

In practice it doesn't seem to matter whether the websocket server or the test agent app is started first...in either case, the test agent app will continue to attempt a connection until it succeeds, so building automation around this shouldn't be hard.

Comment 17

[James Lal [:lightsofapollo]]

Correct... the client will try very hard to remain connected (or to get connected initially) :)

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1501761c9726