1178818 - Apps cannot be launched after installing them on Android using the latest Nightly

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Web Apps (PWAs), defect)

Description

[Valentina Virlics [:vvalentina], Ecosystem QA]

Steps to reproduce:
Load MP-stage on your Android device and install an app (i.e. Loqui IM)

Expected results:
The app is installed on your device. The label of the installation button is “Open”. The app can be launched. 

Actual results:
The installation flow starts. User can click “Install”, “Done” and finish the installation. The button label remains free, after staying a while in the “loading” state. The app cannot be launched.

Notes/Issues:
Verified on FF42(Android 4.2.1). Issue is reproducing on MP-stage , MP-dev and MP-prod.
NOT reproduced on release.
Issue is not reproduced on FF OS or desktop.
Ashes ID: d6c95

Comment 1

[u421692]

pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2694ff2ace6a&tochange=c319f262ce3e

Comment 2

[u421692]

Attachment: log_webapp

Comment 3

[u421692]

(In reply to Mihai Pop from comment #1)
> pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=2694ff2ace6a&tochange=c319f262ce3e

Please discard comment #1,
pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a3f280b6f8d5&tochange=2694ff2ace6a

Comment 4

[:Margaret Leibovic]

(In reply to Mihai Pop from comment #3)
> (In reply to Mihai Pop from comment #1)
> > pushlog:
> > http://hg.mozilla.org/mozilla-central/
> > pushloghtml?fromchange=2694ff2ace6a&tochange=c319f262ce3e
> 
> Please discard comment #1,
> pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=a3f280b6f8d5&tochange=2694ff2ace6a

Bug 1175605 is in that range and looks relevant.

Comment 5

[Eugen Sawin [:esawin]]

This looks like a regression caused by the optional change I've made in bug 1175605.

Can you please confirm that this build fixes the issue:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d48b13809409&exclusion_profile=false ?

Comment 6

[Eugen Sawin [:esawin]]

Attachment: 0001-Bug-1178818-Don-t-use-promises-in-DOMApplicationRegi.patch

It is safe to call receiveMessage on a non-fully initialized registry and apparently it is not safe to rely on the promise resolution within the (temporary) proxy object, so I'm reverting the optional change from bug 1175605.

Comment 7

[u421692]

(In reply to Eugen Sawin [:esawin] from comment #5)
> This looks like a regression caused by the optional change I've made in bug
> 1175605.
> 
> Can you please confirm that this build fixes the issue:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=d48b13809409&exclusion_profile=false ?

Verified as fixed on this build:
http://ftp.mozilla.org/pub/mozilla.org/mobile/try-builds/[e-mail]-d48b13809409/try-android-api-11/fennec-42.0a1.en-US.android-arm.apk

Comment 8

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/04a66937c275

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/04a66937c275

Comment 10

[Valentina Virlics [:vvalentina], Ecosystem QA]

Issue is still reproducing on FF42(Android 4.2.1) on MP-dev.
Issue is not reproduced on clean profile.
Ashes ID: 3b8e3
Reopening.

Comment 11

[Eugen Sawin [:esawin]]

(In reply to ValentinaP from comment #10)
> Issue is still reproducing on FF42(Android 4.2.1) on MP-dev.
> Issue is not reproduced on clean profile.
> Ashes ID: 3b8e3
> Reopening.

Can you please explain when it is still reproducing? You don't have to clean your profile with the fixed version, but you would have to reinstall the app.

Comment 12

[Valentina Virlics [:vvalentina], Ecosystem QA]

(In reply to Eugen Sawin [:esawin] from comment #11)
> Can you please explain when it is still reproducing? You don't have to clean
> your profile with the fixed version, but you would have to reinstall the app.

Yeah, you were right. :)
After reinstalling Nightly, I could not reproduce anymore the issue from comment #0.
Closing bug.

Comment 13

[Valentina Virlics [:vvalentina], Ecosystem QA]

The part, of the initial issue, referring at not being able to launch the installed app is reproducing again in Marketplace, on the latest Nightly available online (FF 42.0a1 from 17.07.2015), but only for packaged apps.

I don't know is this issue has the same root as the previous. (If not, I'll log another issue)
Please take a look (Ashes ID: b14e7)
Thanks!

Comment 14

[Eugen Sawin [:esawin]]

This looks like a different issue, connected to bug 1171013 but it's not a regression from bug 1175605 (maybe a new regression range would help).

We fail to (lazy) load msgmgr (via contract "@mozilla.org/system-message-internal;1") in the case where we use the same Fennec instance for both, installing and loading the webapp. Loading from a different (same version) Fennec instance seems to work, which is strange.

Valentina, can you please file a new bug on this?

Comment 15

[Valentina Virlics [:vvalentina], Ecosystem QA]

(In reply to Eugen Sawin [:esawin] from comment #14)
> This looks like a different issue, connected to bug 1171013 but it's not a
> regression from bug 1175605 (maybe a new regression range would help).
> 
> We fail to (lazy) load msgmgr (via contract
> "@mozilla.org/system-message-internal;1") in the case where we use the same
> Fennec instance for both, installing and loading the webapp. Loading from a
> different (same version) Fennec instance seems to work, which is strange.
> 
> Valentina, can you please file a new bug on this?

I will. Thanks!
Closing this issue due to comment 14.

Comment 16

[Eugen Sawin [:esawin]]

Attachment: 0002-Bug-1178818-Don-t-init-webapp-runtime-before-applica.patch

I'm not sure what has changed since the first patch has landed, but we're getting an issue now when trying to load a webapp before the registry has finished initializing.

What happens is that we call _loadWebapp in browser.js before the registry has been initialized, which for some reason causes an error when Webapps.jsm's init function tries to lazy-load the SystemMessagesInternal service (Cc["@mozilla.org/system-message-internall;1"] is undefined).

Waiting for the registry to initialize and import the messages service before initializing WebappRT.js solves the issue.

Comment 17

[Eugen Sawin [:esawin]]

Let's keep it in this bug after all, this is more closely related than I have first assumed.

Comment 18

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

Comment on attachment 8637475 [details] [diff] [review]
0002-Bug-1178818-Don-t-init-webapp-runtime-before-applica.patch

(In reply to Eugen Sawin [:esawin] from comment #16)
> 
> What happens is that we call _loadWebapp in browser.js before the registry
> has been initialized, which for some reason causes an error when
> Webapps.jsm's init function tries to lazy-load the SystemMessagesInternal
> service (Cc["@mozilla.org/system-message-internall;1"] is undefined).

In my initial testing without this change, I didn't see the problem for both of the packaged apps.  It didn't happen for CutTheRope, but it did happen for Loqui IM.  In subsequent testing, I started seeing it for CutTheRope too.

And then I managed to reproduce with this change.  It seems like firstrun works, but second run fails.  So I don't think this quite fixes the issue.  My steps to reproduce (probably more complex than they need to be):

1. Install both apps via unmodified Fennec.
2. Uninstall Fennec, rebuild with change, and reinstall.
3. Run both apps, kill both apps, run one app again.

(Probably you can simply install a single app with the modified version of Fennec, run it once, kill it, and run it again.)

Comment 19

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

Attachment: include system message components

One problem is that the system message components need to be included in the package.  This fixes the problem for CutTheRope, although Loqui still fails to run on subsequent run.  It doesn't throw that error, however, so that looks like a different problem.

Comment 20

[Eugen Sawin [:esawin]]

Comment on attachment 8637935 [details] [diff] [review]
include system message components

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

I couldn't reproduce using your steps from comment 18, but I've realized why my second patch (sometimes) works.

We have a race condition between Webapps.jsm init and WebappRT.js init. When WebappRT init manages to set dom.sysmsg.enabled before Webapps.jsm init calls loadAndUpdateApps -> registerAppsHandlers, we fail on accessing the system messages service because it's not packaged.

Delaying importing Webapps.jsm simply tightened the race condition, which is why we haven't seen the failures before landing bug 1171013.

Your patch looks good and also means that we have had broken web activities support.

I don't have any issues loading/installing webapps with this patch (without my second patch), can you reproduce the issue?

Comment 21

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/eea1f32a8e25

Comment 22

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

(In reply to Eugen Sawin [:esawin] from comment #20)
> I don't have any issues loading/installing webapps with this patch (without
> my second patch), can you reproduce the issue?

I can't reproduce after reinstalling the apps.  Perhaps the app installation got into a bad state because of the startup failure.  In any case, that would be a different bug, so I'll file a new bug for it if I see it again.

Comment 23

[Carsten Book [:Tomcat]]

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

Comment 24

[Matthew N. [:MattN]]

https://hg.mozilla.org/mozilla-central/rev/eea1f32a8e25