I have Firefox Beta on my android device and have a few apps installed from the Marketplace. I'm seeing multiple prompts about available updates. See attached screenshot. Let me know what other information I can provide. Thanks.

I encountered this problem this evening on my daily driver and pulled its log to investigate. One of the two notifications on my phone came from a Fennec Nightly process, but the other came from a webapp process: 767 ActivityManager I Start proc org.mozilla.fennec:org.mozilla.fennec.Webapp14 for activity org.mozilla.fennec/org.mozilla.gecko.webapp.Webapps$Webapp14: pid=10757 uid=10146 gids={50146, 3003, 1028, 1015} … 10757 Gecko I periodic check for webapp updates 10757 GeckoWebappManager D checkForUpdates 10757 GeckoWebapps D getAll … 10757 Gecko I _notify: Retrieving 1 update… 10757 GeckoWebappManager D _downloadApk for https://mobile.twitter.com/cache/twitter.webapp 10757 GeckoWebappManager D downloading APK from https://controller.apk.firefox.com/application.apk?manifestUrl=https%3A%2F%2Fmobile.twitter.com%2Fcache%2Ftwitter.webapp 10757 GeckoWebappManager D downloading APK to /storage/emulated/0/Download/httpsmobiletwittercomcachetwitterwebapp-45.apk 10757 GeckoWebappManager.. D onreadystatechange: 2 10757 GeckoWebappManager.. D onreadystatechange: 3 10757 GeckoWebappManager.. D onprogress: received 16231 bytes 10757 GeckoWebappManager.. D onprogress: wrote 16231 bytes 10757 GeckoWebappManager.. D onreadystatechange: 3 10757 GeckoWebappManager.. D onprogress: received 9711 bytes 10757 GeckoWebappManager.. D onprogress: wrote 9711 bytes 10757 GeckoWebappManager.. D onreadystatechange: 4 10757 Gecko I _notify: 1 update downloaded That isn't supposed to happen, because the update timer checks browser.webapps.checkForUpdates: http://mxr.mozilla.org/mozilla-central/source/mobile/android/components/WebappsUpdateTimer.js?rev=9fb35ece0bde#36 Which is set to 0 (zero), i.e. disabled, in webapp profiles, per: http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/WebappRT.js?rev=61ee3167a1d2#40 But bug 1026263 means that pref sometimes doesn't get set, and I bet that's why this bug occurs. So this bug depends on that one. Nevertheless, there's something we could do here to resolve this problem before we figure out that one: we can register the update timer programmatically instead of declaratively, like the desktop runtime does <http://mxr.mozilla.org/mozilla-central/source/webapprt/WebappRT.jsm?rev=89076de4e3c3#100>, so it only gets registered in the browser process.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #1) > But bug 1026263 means that pref sometimes doesn't get set, and I bet that's > why this bug occurs. So this bug depends on that one. Erm, that's incorrect. That bug may prevent the app.orientation.default pref from being set, but the others, including browser.webapps.checkForUpdates, are set in a different place that isn't affected by that bug. So I'm breaking the dependency relationship. Nevertheless, I still suspect the pref isn't getting set appropriately, and I'm leery of our code for determining firstrun and setting prefs accordingly. Not to mention that this isn't something that should be pref-controllable. So I'm thinking we should make this pref-independent, using some other mechanism to determine that we're in a webapp process. But I'm not sure what that is. I suppose we could check the profile name, which is what GeckoProfile does: http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoProfile.java?rev=bf683354136b#302 We could also check the name of the activity class, to see if it matches the webapp pattern; perhaps via an updated JNI.jsm from bug 918309 that supports calling non-static methods.

Here's a patch that uses the new JNI module to check the activity context's class name to determine whether or not WebappsUpdateTimer is in a webapp process. Along the way, I switched WebappsUpdateTimer to use AndroidLog, and I removed the log message that says the timer isn't doing anything, since that starts to get annoying once you have a few apps. But I left the browser.webapps.checkForUpdates pref around, since test harnesses seem to use that to disable update checks during test runs that don't have external network access.

Comment on attachment 8471405 [details] [diff] [review] patch v1: use JNI to determine if in webapp process for automatic update check Review of attachment 8471405 [details] [diff] [review]: ----------------------------------------------------------------- ::: mobile/android/base/tests/testJNI.js @@ +46,5 @@ > + methods: [ > + { name: "getName", sig: "()Ljava/lang/String;" }, > + ], > + }); > + do_check_eq("org.mozilla.gecko.BrowserApp", JNI.ReadString(jenv, geckoAppShell.getContext().getClass().getName())); Completely unrelated, but we should have put dev-doc-needed in the JNI.jsm bug. I don't know if those guys have time, but if you're ever feeling bored, some docs would be nice.

(In reply to Wesley Johnston (:wesj) from comment #4) > Completely unrelated, but we should have put dev-doc-needed in the JNI.jsm > bug. I don't know if those guys have time, but if you're ever feeling bored, > some docs would be nice. Indeed, so I added dev-doc-needed to that bug!