826146 - Need way to bypass app install prompt from test code

Status: RESOLVED FIXED

(Core Graveyard :: DOM: Apps, defect)

Description

[Bobby Holley (:bholley)]

When running B2G mochitests, installing an app is impossible because there's nothing hooked up to listen for "webapps-ask-install" (normally handled by gaia).

We should add a pref that can be frobbed via SpecialPowers.

Comment 1

[Bobby Holley (:bholley)]

CCing some people who might be interested in knowing that this is happening.

Comment 2

[Bobby Holley (:bholley)]

Attachment: Add a pref-controlled install confirmation override for automation. v1

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 697742 [details] [diff] [review]
Add a pref-controlled install confirmation override for automation. v1

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

We could also have the tests call pushPrefEnv directly. Totally up to you.

Comment 4

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1024e72d4ef9

Comment 5

[(no longer active)]

Backed out because of test failures: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=1024e72d4ef9

https://hg.mozilla.org/integration/mozilla-inbound/rev/e9cbccc2814c

Comment 6

[Jason Smith [:jsmith]]

Looks like this patch broke the existing mochitest chrome tests we have for webapps.

Comment 7

[(no longer active)]

(In reply to comment #6)
> Looks like this patch broke the existing mochitest chrome tests we have for
> webapps.

Yes, but it was backed out because of that.  See comment 5.

Comment 8

[Bobby Holley (:bholley)]

Sigh, I forgot that get*Pref doesn't have sane defaults.

Sicking - Would you prefer hasUserValue && getBoolPref, or a default value in b2g.js?

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I would say do hasUserValue && getBoolPref. That way the pref won't show up in about:config etc.

Comment 10

[Mounir Lamouri (:mounir)]

Note that pushPrefEnv, as weird as it is, doesn't pop the pref at the end of the test. You have to do that yourself using popPrefEnv.

Comment 11

[Bobby Holley (:bholley)]

(In reply to Mounir Lamouri (:mounir) from comment #10)
> Note that pushPrefEnv, as weird as it is, doesn't pop the pref at the end of
> the test. You have to do that yourself using popPrefEnv.

Uh, really? I'm pretty sure it does, via a call to flushPrefEnv in the test runner:

http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/tests/SimpleTest/TestRunner.js#453

That's half the point of the API. Indeed, the only calls to {push,flush}PrefEnv are in the test harness.

Comment 12

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/13c525135b4a

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Erm, it would be better to add a method to the special powers API that registers a webapps-ask-install listener that auto-approves install requests.

We used to have exactly such a pref, but we removed it, and I don't remember exactly why, but I think it was the result of a security review that flagged it as problematic, because it enables users to disable these prompts by setting a pref; and not just in B2G, but also on Android and desktop.

cc:ing some security folks who might remember the context around that call.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Registering an observer that simply calls through wouldn't prevent the existing observer code from popping up the existing security UI, would it?

I'm definitely interested if we can find better solutions though.

Comment 15

[Myk Melez [:myk] [@mykmelez]]

(In reply to Jonas Sicking (:sicking) from comment #14)
> Registering an observer that simply calls through wouldn't prevent the
> existing observer code from popping up the existing security UI, would it?

It wouldn't, but doesn't comment 0 say there's nothing hooked up to observe the notification?

If there is something hooked up to observe the notification, there are still other options.  When we removed the pref, we modified the desktop mozApps mochitests to programmatically press the Install button in Firefox's Confirm Install doorhanger using SpecialPowers in the confirmNextInstall() function:

http://hg.mozilla.org/mozilla-central/file/9ea498433661/dom/tests/mochitest/webapps/head.js#l47

Comment 16

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/13c525135b4a

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 697742 [details] [diff] [review]
Add a pref-controlled install confirmation override for automation. v1

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

Approval for b2g18 since this is very low risk (simple and well tested at this point), and will help us write tests for the b2g code that we'll be shipping.

I do agree that having a pref is not great, but it's not really a problem on b2g since we don't have about:config there. So uplifting to that branch doesn't seem like a problem.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

But don't forget to uplift the followup fix of course.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/d810d8e8b723