Closed Bug 989095 Opened 7 years ago Closed 6 years ago

Force Stop button in Android "Settings | Apps | [appname]" page has no effect on Web Apps

Categories

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

x86_64
Linux
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: dholbert, Unassigned)

Details

(Whiteboard: [WebRuntime])

STR:
 1. In Firefox Nightly for Android, install and run WeatherFox (as an example; applies to other apps as well, AFAICT): https://marketplace.firefox.com/app/weatherfox

[OPTIONAL:]
 2. Tap WeatherFox's "menu" button in upper-left. Note the UI change.
 3. Tap your Android app-switcher button (looks like 2 stacked rectangles on my phone), and swipe WeatherFox away to kill it.
 4. Re-launch WeatherFox. **Note that it takes a second to load, and goes to the main page (not the settings page). This indicates that you did actually kill it.
[/OPTIONAL]

 5. With WeatherFox at its Menu page, open Android Settings.
 6. In Settings, go to Apps | WeatherFox, and press the Force Stop button. (note that it grays out, implying that it did something)
 7. Re-launch WeatherFox, or choose it from the app-switcher.

ACTUAL RESULTS: WeatherFox immediately pops up, still at its Menu page, indicating that the "Force Stop" button did not actually kill it.

EXPECTED RESULTS: We should've honored whatever signal the "Force Stop" button sends (and kill the app at least as effectively as swiping it away in the app-switcher does, in the [optional] steps).
Summary: Force Stop has no effect on Web Apps → Force Stop button in Android "Settings | Apps | [appname]" page has no effect on Web Apps
(I'm using up-to-date Firefox Nightly on a Nexus 4.)
Or maybe not, if bug 958709 is in Daniel's up to date Nightly.
Per my [OPTIONAL] section in STR, swiping apps away in the app-switcher (aka recents screen) does successfully close them. So, bug 958709 is fixed in my nightly, and this is not a dupe of that.
Bug 958709 is fixed in Fennec, but it needs a corresponding fix to the APK Factory library, which hasn't yet made it to production.  So I think this is indeed a duplicate of that bug.  Marking as such, but please reopen this bug if you can continue to reproduce after the library fix has been pushed to production (tomorrow?) and you update to the new APK it produces!
Status: NEW → RESOLVED
Closed: 7 years ago
Priority: -- → P1
Resolution: --- → DUPLICATE
Whiteboard: [WebRuntime]
Duplicate of bug: 958709
needinfo=me to remind myself to check on whether this is fixed after a day or two, per comment 5.
Flags: needinfo?(dholbert)
I can still reproduce this, but as I understand it, the APK Factory update's deployment has been delayed, as noted in bug 988741 comment 18.  So, I assume it's expected that this should still be broken.
I can still reproduce this with STR from comment 0. Has the APK factory update gone live yet?

If so, I expect we should reopen this?

(FWIW, if I try the STR with a different open web app -- twitter -- I hit bug 995803. So the "force stop" button does have some effect in that case, but still no apparent effect with WeatherFox.)
Flags: needinfo?(dholbert) → needinfo?(myk)
(I also don't think I've received a WeatherFox app update since Comment 5; I guess that means either the APK factory update is still pending, or if it didn't generate app-updates in the way we expected it to?)
I think the APK Factory update has now been pushed to production.  But I too didn't get prompted for updates for all the apps I've been dogfooding, come to think of it.  And I still see the same behavior.  So perhaps the library update didn't prompt the factory to invalidate its APK cache for all apps, as it was supposed to do.

ozten: do you know whether or not that happened?
Flags: needinfo?(myk) → needinfo?(ozten.bugs)
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
If I grab weatherfox
http://rishabhsrao.github.com/weather-fox/dist/manifest.webapp
In the APK I see version 1394217122

Using the update API

    curl -v -H "Content-Type: application/json" -X POST -d '{ "installed":{"http://rishabhsrao.github.com/weatnifest.webapp":1394217122}}' https://controller.apk.firefox.com/app_updates
    {"outdated":[]}
(In reply to Austin King [:ozten] from comment #11)
> Can we list manifest urls that have issues?

They all do, as the fix involved a library change, and when the library changes, then all APKs have to be regenerated to pick up the change.

The bug in question is bug 958709, and the library change landed 26 days ago in this pull request <https://github.com/mozilla/apk-factory-library/pull/2>.  If the APK Factory service has been updated to use the newer version of the library, then we just need to invalidate the entire APK cache.  Otherwise we'll first need to update the service to use the newer version.
I've edited VER.txt from 1 to 2.

https://github.com/mozilla/apk-factory-library/commit/9a6a7efe723f40f8a1a622bb7c90eec8e4b57e5d

This invalidates the cache and will cause a re-build of apks with version 1 library code (which is all existing ones).

We will push to production this Tuesday (normal Marketplace release cycle).

We should test stage to verify this fix. re-pushing stage now.
This is not a dupe of Bug 958709.

The fix for this bug is described in Bug 958709 Comment 18 and may also fix Bug 958709.
Per bug 1235869, we're going to disable the Android web runtime, so we won't fix this bug in it.

(This is part of a bulk resolution of bugs in the Firefox for Android::Web Apps component, from which I attempted to exclude bugs that are not specific to the runtime, but it's possible that I included one accidentally.  If so, I'm sorry, and please reopen the bug!)
Status: REOPENED → RESOLVED
Closed: 7 years ago6 years ago
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.