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?

(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.

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.

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.

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?

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 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 ;)

Pointer to Github pull-request

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.

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.

(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.

Is the gecko patch ready to land now?

@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?

(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.

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