Closed Bug 1178818 Opened 5 years ago Closed 5 years ago

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

Categories

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

42 Branch
Unspecified
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 42
Tracking Status
firefox42 --- fixed
fennec 40+ ---

People

(Reporter: vvalentina, Assigned: esawin)

Details

(Keywords: productwanted)

Attachments

(3 files, 1 obsolete file)

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
Component: Consumer Pages → Web Apps
Product: Marketplace → Firefox for Android
Target Milestone: 2015-06-30 → ---
Version: Avenir → Firefox 42
tracking-fennec: --- → ?
Attached file log_webapp
(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
(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.
Flags: needinfo?(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 ?
Flags: needinfo?(esawin) → needinfo?(mihai.g.pop)
Assignee: nobody → esawin
Status: NEW → ASSIGNED
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.
Attachment #8631767 - Flags: review?(myk)
Attachment #8631767 - Flags: review?(myk) → review+
(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/esawin@mozilla.com-d48b13809409/try-android-api-11/fennec-42.0a1.en-US.android-arm.apk
Flags: needinfo?(mihai.g.pop)
https://hg.mozilla.org/mozilla-central/rev/04a66937c275
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 42
Issue is still reproducing on FF42(Android 4.2.1) on MP-dev.
Issue is not reproduced on clean profile.
Ashes ID: 3b8e3
Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
(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.
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
tracking-fennec: ? → 40+
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!
Status: VERIFIED → REOPENED
Flags: needinfo?(esawin)
Resolution: FIXED → ---
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?
Flags: needinfo?(esawin)
(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.
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
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.
Attachment #8637475 - Flags: review?(myk)
Let's keep it in this bug after all, this is more closely related than I have first assumed.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.)
Attachment #8637475 - Flags: review?(myk) → review-
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.
Attachment #8637935 - Flags: review?(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?
Attachment #8637935 - Flags: review?(esawin) → review+
Attachment #8637475 - Attachment is obsolete: true
(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.
https://hg.mozilla.org/mozilla-central/rev/eea1f32a8e25
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.