988741 - Daily update notifications for Summit open web app, which immediately fail when accepted

Status: VERIFIED FIXED

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

Description

[Daniel Holbert [:dholbert]]

For the last week or so, I've been getting daily update offers for the "Summit" open web app (the official app for the Mozilla Summit 2013), in my Android notification bar.

If I accept the update offer, it immediately changes to "1 download failed".

Here's the logcat output from me accepting the update just now:
{
03-26 23:29:04.216 I/Gecko   ( 6035): _notify: Downloading 1 update…
03-26 23:29:04.226 W/InputMethodManagerService( 1367): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy@42c605e8 attribute=null, token = android.os.BinderProxy@4292f9e8
03-26 23:29:04.246 E/Profiler( 6035): BPUnw: [6 total] thread_register_for_profiling(me=0x852ed570, stacktop=0x770fdb5f)
03-26 23:29:05.067 I/Gecko   ( 6035): WebManagerWorker onreadystatechange: 2
03-26 23:29:05.067 I/Gecko   ( 6035): WebManagerWorker onreadystatechange: 3
03-26 23:29:05.067 I/Gecko   ( 6035): WebManagerWorker onprogress: received 79 bytes
03-26 23:29:05.067 I/Gecko   ( 6035): WebManagerWorker onprogress: wrote 79 bytes
03-26 23:29:05.067 I/Gecko   ( 6035): WebManagerWorker onreadystatechange: 4
03-26 23:29:05.077 I/Gecko   ( 6035): _notify: 1 download failed
}

Not sure what's going on, but this is definitely undesirable, as I'm getting bugged once a day for an apparently nonexistent update with no obvious way to stop it.

Also, AFAICT, I don't even have the summit app on my phone anymore; it doesn't appear in my normal applications menu, or in my apps list in Android settings.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot after I accepted the update

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Does it appear in Fennec? Try the main menu: Tools > Apps
And see if it's in the list.

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Mark Finkle (:mfinkle) from comment #2)
> Does it appear in Fennec? Try the main menu: Tools > Apps
> And see if it's in the list.

Ah, yes - it does appear there. Thanks! So that part of the mystery is solved.

The "Check for Updates" button on that page produces the update notification, too. (i.e. it lets me reproduce this bug more frequently than once a day)

Comment 5

[Daniel Holbert [:dholbert]]

For completeness, here's the (brief) adb logcat output when I hit "check for updates":
{
03-27 08:08:54.054 I/Gecko   ( 9573): _notify: Checking for updates…
03-27 08:08:54.234 I/Gecko   ( 9573): _notify: 1 new update
}

Comment 6

[Daniel Holbert [:dholbert]]

(Oddly, when I tap the icon for the Summit App in my fennec Apps page, it launches using the URL for *other* app that I have installed, WeatherFox.)

Comment 7

[Aaron Train [:aaronmt]]

I wonder if this is happening for all "legacy" web applications. They think they have updates.

Comment 8

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

All legacy apps do have updates, but they should be succeeding, not failing.  This may be a factory problem with the particular app(s) in question, in which case we should fix that problem.  But either way, we shouldn't leave anyone in this state, so there's definitely a client fix here.

Perhaps we should back off (or stop) trying to update legacy apps after a failure.  Or at least allow users to uninstall them from about:apps, which used to be possible, but which we removed, because the new implementation expects users to uninstall them via the native Android flow (which isn't possible if the update to a synthetic APK fails, putting users into a catch-22).

Comment 9

[Austin King [:ozten]]

What is the URL to the mini manifest? or to the install page?

I searched on marketplace and do not see it.

Comment 10

[Richard Newman [:rnewman]]

Possibly peripherally related: every time I load Tools > Apps in Fennec, the icons for all apps load fast… apart from the Summit app, which takes a few seconds.

Neither of the 'legacy' web apps (Summit, Firetext) allows me to launch it from Fennec.

I don't know how to get the URL for the app out of Fennec...

Comment 11

[Daniel Holbert [:dholbert]]

I don't think the summit app was in the marketplace. I also don't think it was in the marketplace. I think it was hosted at http://summit.mozilla.org/ or somewhere like that, though (which maybe was able to pop up an "install as web app" notification or something? I don't remember.)

There's a blog post about the app, from williamr, here:
  http://dailycavalier.com/2013/12/the-summit-app/

He might know whether it's still hosted anywhere. (At the end of the blog post, it says the source code is public: https://github.com/mozilla/firehug )

Comment 12

[William Reynolds [:williamr]]

(In reply to Austin King [:ozten] from comment #9)
> What is the URL to the mini manifest? or to the install page?
> 
> I searched on marketplace and do not see it.

The Summit app was listed on the marketplace in October 2013, but it was remove when it was retired after the event. The source still exists if you want to see the manifest:
https://github.com/mozilla/firehug/blob/master/public/manifest.webapp

The last commit in the repo was six months ago, so I don't think the issue discussed in this bug was caused by a recent update to the app. From what I can tell, the app has not been updated in months and is not currently hosted anywhere.

Comment 13

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

My theory is that:

* the user installs an app on a version of Fennec with the old runtime;
* the app (or at least its manifest URL) becomes unavailable;
* the user then updates to a version of Fennec with the new runtime;
* Fennec checks for updates, and APK Factory says there's an update available;
* Fennec requests the APK, but APK Factory fails to build it;
* rinse and repeat.

To test this theory, I did the following:

* created a hosted app on a new domain that APK Factory has never seen before (so can't have cached an APK for);
* installed a custom build of Fennec with synthetic APKs disabled (i.e. using the old runtime);
* installed the app;
* removed the app from its host;
* updated to a build with synthetic APKs enabled (i.e. using the new runtime);
* checked for updates.

Fennec found an update for the app:

 25571                  Gecko  I  checkForUpdates
 25571                  Gecko  I  _notify: Checking for updates…
 25571                  Gecko  I  _notify: 1 new update

So I told it to download the update, and the download failed:

 25571                  Gecko  I  _notify: Downloading 1 update…
 25571                  Gecko  I  _downloadApk for http://melez.com/app/manifest.webapp
 25571                  Gecko  I  downloading APK from https://controller.apk.firefox.com/application.apk?manifestUrl=http%3A%2F%2Fmelez.com%2Fapp%2Fmanifest.webapp
 25571                  Gecko  I  downloading APK to /storage/emulated/0/Download/httpmelezcomappmanifestwebapp.apk
 25571                  Gecko  I  WebManagerWorker onreadystatechange: 2
 25571                  Gecko  I  WebManagerWorker onreadystatechange: 3
 25571                  Gecko  I  WebManagerWorker onprogress: received 2 bytes
 25571                  Gecko  I  WebManagerWorker onprogress: wrote 2 bytes
 25571                  Gecko  I  WebManagerWorker onreadystatechange: 4
 25571                  Gecko  I  error downloading APK: 400 - Bad Request
 25571                  Gecko  I  _notify: 1 download failed


Perhaps the APK Factory thinks there's an update because Fennec tells it the version code of the app is "0", and it knows that "0" means "legacy shortcut", so it assumes there'll be a synthetic APK update.  Or maybe it assumes that there's always an update for an app for which it doesn't have a cached APK, because the APK it eventually caches should always be newer than whatever Fennec has.  Either way, the factory should ensure it can create an APK before it tells the client that an update is available.

Still thinking about what we should do on the client side to guard against something like this…

Comment 14

[Austin King [:ozten]]

Great find!

Comment 15

[Austin King [:ozten]]

Fixed in https://github.com/mozilla/apk-factory-service/pull/64

Deploying to dev.

Comment 17

[Richard Newman [:rnewman]]

ETA on deployment? Or do we need to file a deployment ticket?

Comment 18

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

(In reply to Richard Newman [:rnewman] from comment #17)
> ETA on deployment? Or do we need to file a deployment ticket?

It was delayed from Tuesday to Wednesday because it was bundled with the AMO/Marketplace deployments, which were delayed a day.  Then, when we deployed it on Wednesday, the deployment failed and was rolled back.

In this dev.marketplace thread about the deployments <https://groups.google.com/forum/#!topic/mozilla.dev.marketplace/gKqpaLatFoQ>, Austin says: "We will work on this after the Marketplace production push and once we've got a solid release, we'll do an out of cycle production push, assuming Ops has the bandwidth."

Comment 19

[Richard Newman [:rnewman]]

Gotcha, thanks for the update. Wasn't sure where this stood, 'cos I was still seeing the behavior and didn't see any bug activity.

Comment 20

[Austin King [:ozten]]

This is staged, ready for testing.

Comment 21

[Daniel Holbert [:dholbert]]

I can confirm that I've stopped receiving these daily update notifications. (And doing a manual "Check for updates" no longer gives me an update notification for the Summit app, either.)

--> Setting to VERIFIED.