1035867 - Fail to launch webapp with TypeError: navigator.mozApps is undefined

Status: VERIFIED FIXED

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

Description

[Bob Clary [:bc] (inactive)]

Attachment: webapp-startup-test.apk

1. adb install webapp-startup-test.apk

2. adb shell 'am start  -n com.firefox.cli.apk.webappstartupperformancetestbclary.pc91282b8e6a
542101851c47a670b9c8c/org.mozilla.android.synthapk.LauncherActivity -a android.intent.action.MAIN --es env0 MOZ_CRASHREPORTER_NO_REPORT=1'

E/GeckoConsole(18340): Full Message: {file: "chrome://browser/content/WebappRT.js" line: 83 column: 0 source: "83"}]

Full message: TypeError: navigator.mozApps is undefined
Full stack: WebappRT.getManifestFor/<@chrome://browser/content/WebappRT.js:83:11
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:866:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:745:7
this.DOMApplicationRegistry.doGetList@resource://gre/modules/Webapps.jsm:1134:7
this.DOMApplicationRegistry.receiveMessage@resource://gre/modules/Webapps.jsm:1005:1
init@resource://gre/modules/AppsServiceChild.jsm:111:16
@resource://gre/modules/AppsServiceChild.jsm:391:1
@jar:jar:file:///data/app/org.mozilla.fennec-1.apk!/assets/omni.ja!/components/Webapps.js:15:1
WebappRT.getManifestFor/<@chrome://browser/content/WebappRT.js:83:11
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:866:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:745:7

good: http://hg.mozilla.org/integration/mozilla-inbound/rev/f81fe2b04fef
bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/b2fd5a214d2a
Maybe bug 903291 ? I'm trying to bisect now.

Comment 1

[Bob Clary [:bc] (inactive)]

Ran a bisection looking for WEBAPP STARTUP COMPLETE in logcat and found:

The first bad revision is:
changeset:   192594:ea4acc8b76dd
user:        Fernando Jiménez <[e-mail]>
date:        Sat May 24 12:28:13 2014 -0700
summary:     Bug 903291 - App download hangs indefinitely if the child process dies before confirming the install. r=fabrice

I'll double check looking for TypeError: navigator.mozApps is undefined

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Bug 903291 was backed out, but hopefully we can find a way to test for this regression when it eventually re-lands?

Comment 4

[Bob Clary [:bc] (inactive)]

This regressed again after landed. I confirmed with 

http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-central-android/1406196121/

20140724030201
https://hg.mozilla.org/mozilla-central/rev/a91ec42d6a9c

Comment 5

[Bob Clary [:bc] (inactive)]

manually checking m-c i get

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=66cb4d556959&tochange=a91ec42d6a9c

Comment 6

[Antonio Manuel Amaya Calvo (:amac)]

Attachment: Remove the DOMApplicationRegistry.registryReady promise check

I don't have a android build tree... nor an Android phone, actually, which is going to make this interesting :P

Could you please check to see if this fixes the problem?

Comment 7

[Bob Clary [:bc] (inactive)]

Fabrice, I keep getting an unrelated build error on mozilla-inbound:

13:09.24 invalid resource directory name: /mozilla/builds/inbound/mozilla/mobile/android/branding/official/res/drawable-xxxhdpi
13:09.24 make[5]: *** [.aapt.deps] Error 1
13:09.24 make[5]: *** Deleting file `.aapt.deps'
13:09.24 make[5]: *** Waiting for unfinished jobs....

Can someone who can get a build completed test the patch?

Comment 8

[Bob Clary [:bc] (inactive)]

fyi, i'm building with --with-android-sdk=/home/bclary/opt/android-sdk-linux/platforms/android-17 Is that no longer supported?

Comment 9

[Antonio Manuel Amaya Calvo (:amac)]

Attachment: Logcat from my try

Ok, I installed Android on my Peak, and compiled Fennec (using android 19 and copying ziptool from an old sdk I had around since the new one doesn't have it anymore it seems).

I installed it on the phone and ran the APK of comment 0... and I don't know if what I get is expected or not :)

The browser starts, shows a bot icon with a square and then a white screen. In the logcat I don't get the mozApps exception anymore (I get a Java exception though). Attached is the logcat from running the APK.

Comment 10

[Antonio Manuel Amaya Calvo (:amac)]

Then again, I get exactly the same behavior without the patch...

Comment 11

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

(In reply to Bob Clary [:bc:] from comment #8)
> fyi, i'm building with
> --with-android-sdk=/home/bclary/opt/android-sdk-linux/platforms/android-17
> Is that no longer supported?

It's still supported, in fact it's the default in releng mozconfigs:

http://hg.mozilla.org/mozilla-central/annotate/06ac51c2b8a8/mobile/android/config/mozconfigs/common#18

I'm building now and will test shortly.

Comment 12

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

Comment on attachment 8461592 [details] [diff] [review]
Remove the DOMApplicationRegistry.registryReady promise check

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

(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #9)
> The browser starts, shows a bot icon with a square and then a white screen.

Does the white screen display the text "Done!" at the top?  If so, you've successfully launched and run the app.  Otherwise, you're experiencing a "white screen of sorrow," which is a class of bugs in the startup process after the splash screen (bot icon with square) is hidden but before the app is rendered.


> In the logcat I don't get the mozApps exception anymore (I get a Java
> exception though). Attached is the logcat from running the APK.

Hmm, I don't see a Java exception in this log.


Strangely, this fixes the problem, although I don't understand how, and I'm worried that it'll introduce problems in the future.  Can you explain the reasoning behind no longer awaiting registryReady?

Comment 13

[Antonio Manuel Amaya Calvo (:amac)]

I'm getting a white screen of sorrow then :). 

registryReady is not needed because the mozApps constructor sends a sync message to Webapps.jsm. And that message isn't answered until the registry is ready. So
navigator.mozApps only returns after the registry is ready no matter how's it called. 

And to be honest, I'm not sure either why removing that promise makes it work. I knew, though, that I got a problem on some builds when it was waiting on that promise inside of doGetList. I solved that by using a promise that's resolved earlier and doesn't depend on receiving a message to being fulfilled (it's resolved when the registry is read, not when the activities are ready). And I had hunch this might be the same problem.

Comment 14

[Antonio Manuel Amaya Calvo (:amac)]

I'll send a try push later on and request review then.

Comment 15

[Antonio Manuel Amaya Calvo (:amac)]

Try run is at:
https://tbpl.mozilla.org/?tree=Try&rev=89e36929e2ae


Oh, about the Java exception, my bad, I thought the
D/StrictMode( 5815): 	at org.mozilla.gecko.util.HardwareUtils.getMemSize(HardwareUtils.java:168)
D/StrictMode( 5815): 	at org.mozilla.gecko.GeckoAppShell.getScreenDepth(GeckoAppShell.java:1304)
...
were part of a exception stack dump.

Comment 16

[Bob Clary [:bc] (inactive)]

The try build works for me. Let's get this landed so Autophone can go back to testing webapp startup times.

Comment 17

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

Comment on attachment 8461592 [details] [diff] [review]
Remove the DOMApplicationRegistry.registryReady promise check

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

(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #13)
> I'm getting a white screen of sorrow then :). 
> 
> registryReady is not needed because the mozApps constructor sends a sync
> message to Webapps.jsm. And that message isn't answered until the registry
> is ready. So
> navigator.mozApps only returns after the registry is ready no matter how's
> it called. 

Ah, good point!


> And to be honest, I'm not sure either why removing that promise makes it
> work. I knew, though, that I got a problem on some builds when it was
> waiting on that promise inside of doGetList. I solved that by using a
> promise that's resolved earlier and doesn't depend on receiving a message to
> being fulfilled (it's resolved when the registry is read, not when the
> activities are ready). And I had hunch this might be the same problem.

Hmm, ok.  We should land this anyway, since it's the right thing to do, but I sure would like to know how navigator.mozApps can be undefined after awaiting registryReady.  I read through the code in bug 903291, and I don't see any reason for it to cause this problem.  I'll continue to think about this issue.

Comment 18

[Bob Clary [:bc] (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8f2c13fb4734

thanks!

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/8f2c13fb4734

Comment 20

[Bob Clary [:bc] (inactive)]

bug 903291 has landed again and this is verified in autophone. thanks all.