1495443 - Download progress notification still displayed after closing app on some devices

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: Download Manager, defect, P2)

Description

[Sorina Florean [:sflorean]]

Environment:
Build: Nightly 64.0a1 (2018/10/01);
Devices: Nexus 5(Android 6.0.1), Motorola Nexus 6(Android 7.1.1), HTC Desire 820 (Android 6.0.1), Google Pixel (Android 9)

Steps to reproduce:
1) Go to https://www.thinkbroadband.com/download;
2) Start downloading something;
3) Close the application before the download is finished;
4) Pay attention to the notification bar.

Expected result:
The download will stop and the notification will disappear.

Actual result:
Nothing happens, the download notification is still displayed. 

Note: If I tap on "cancel" or "pause" the browser is opened (white screen).

Video: https://drive.google.com/open?id=1PkP0yMfZ3xQY2mFjN9_hc57FaRqmpXk-

Comment 1

[Vlad Baicu]

> When trying this in Chrome, the download continues in the background (and
> can be tracked via the built-in Download manager). We should probably do the
> same.

Based on my understanding from Andreas's answer from bug 1478053 the actual result is expected as of the latest changes.

@sorina Even if you close the app, the notification still updates and the download process continues as intended or nothing happens at all and it just stays stuck there ? 

Just to clarify, even if you close the app, the download should continue with an updating notification until it finishes or it gets canceled. This is also how Chrome handles their downloads, except for the action of the notification which opens their download manager. 

> Note: If I tap on "cancel" or "pause" the browser is opened (white screen).
In our case, I'm thinking we should have Fennec open the about:downloads tab when tapping on the notification ? Currently it is trying to show the abort download dialog.

Comment 2

[Sorina Florean [:sflorean]]

Tested again on the latest Nightly build and here are the results:
-For  Nokia 6(Android 7.1.1), Xiaomi Mi Pad 2(Android 5.1), Xiaomi Mi4i(Android 5.0.2) -> after the browser was closed the download notification is not displayed;
- For Samsung Galaxy S8(Android 8.0) -> I got the behavior from bug 1495743(reproducing rate 2/4);
- For Sony Xperia Z2(Android 6.0.1), Samsung Galaxy Tab S3(Android 8.0), Nexus 9(6.0.1), HTC Desire (Android 6.0.1), the behavior is like in the description, the notification is still displayed, and tapping on pause/cancel opens the browser. But I can pause the download. 

@Vlad, to answer your question, yes the notification gets updated even if the browser is closed.

Comment 4

[Pascal Chevrel:pascalc]

Marking 63 as affected and tracking as this should be fixed to uplift the patch in bug 1478053 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1478053#c21)

Comment 5

[Vlad Baicu]

I've had a hard time reproducing this issue on our on-site devices, but I've caught it on a Xiaomi Redmi 5A. Currently working on a fix

Comment 6

[Andreas Bovens [:abovens]]

The action on the notification should indeed open the Fennec download manager.

Comment 7

[Vlad Baicu]

Attachment: Bug 1495443. Notification click action now opens about:downloads. r=sdaswani

Comment 8

[Vlad Baicu]

I have submitted a patch which changes the notification action to display the about:downloads tab instead of the cancel prompt. 

Regarding the zombie/dissapearing notifications I think the way to go would be to refactor the downloads and create a Download Foreground Service in a separate process which takes care of these (for Fennec at least, since this code seems to be shared with the rest of the platforms). This change however requires some JS/Geckoview knowledge above me since the Downloads are currently handled there. A similar implementation is done in Chromium as well (https://github.com/kuoruan/Chromium-Android/tree/master/app/src/main/java/org/chromium/chrome/browser/download).

@susheel, can someone lend us a hand with this problem ?

Comment 9

[Pascal Chevrel:pascalc]

Wontfix for 63 as we are ending our beta cycle.

Comment 10

[:sdaswani]

Jim, any chance you can help on the zombie/disappearing notifications? https://bugzilla.mozilla.org/show_bug.cgi?id=1495443#c8

Comment 11

[(inactive) Jim Chen [:jchen] [:darchons]]

Vlad, you should file a GeckoView bug about the proposed change, and the team will triage and assign a priority to that.

Comment 12

[Vlad Baicu]

Jan, do you have any ideas if there is something else we could try out on our side for this bug ?

Comment 13

[Vlad Baicu]

I think it is worth mentioning that while testing on the Xiaomi Redmi 5A, whenever the app is forcefully closed our downloads and notifications get killed even with the NotificationService running in foreground, whereas the same does not happen on Chrome. 

For what it's worth, I did notice that their DownloadService uses a TaskScheduler to schedule jobs that run in the background which is backed by system APIs (JobScheduler on newer platforms and GCM on older platforms).

Comment 14

[Jan Henning [:JanH]]

First of all we should sort out which bug is about what - currently this bug still claims to be about "Download progress notification still displayed after closing app on some devices" (and is being tracked for that reason), but because this is the intended behaviour the resolution should be WONTFIX.
At the same time thought the discussion seems to have morphed into something different and this bug now has a patch for changing what happens when clicking on the notification, which isn't really related to neither the original issue nor bug 
1495743.

That aside, what you're seeing on Xiaomi is presumably https://stackoverflow.com/questions/47999776/service-stops-whenever-app-is-killed or https://stackoverflow.com/questions/39205852/how-to-restart-background-service-getting-killed-on-redmi-phone-for-mium-8/39269523, so the reason this works for Chrome and not for us might simply be that they are big and get automatically whitelisted and we are small and in their view unimportant and therefore aren't.
Maybe people with Xiaomi phones could check their settings and see if it's possible to determine which apps have been automatically whitelisted and whether Chrome is included among them?
If you absolutely wish, you could also try writing a minimal sample app to check whether using a separate service process actually helps with that issue in the first place.

For now I'd rather concentrate on investigating bug 1497963 and bug 1495743.

As for the Xiaomi issue
- if services running in a separate process actually survive the main app process being killed if its task is swiped away and the app isn't white-listed, in theory snorp's idea of a separate Gecko process might help (i.e. Gecko itself remains single process, but it runs in a separate process from the rest of the app), but that is probably still more trouble than it's worth.
- detect when we're running on Xiaomi and show a (one-time) notification asking the user to white-list us and take them directly to the right screen of the Xiaomi settings app. Maybe we could also find a way to detect interrupted download and only show the notification then [1].
- As far as I can tell, launching Firefox after force stopping it during a download automatically resumes interrupted downloads. Maybe just bringing up Gecko without launching the full UI could already be enough to get interrupted downloads to resume then. If so, maybe we can detect the impending kill via onTaskRemoved() and then schedule a one-shot action if we're currently downloading something in order to restart Gecko in case the whole app process is terminated.

But since that affects only certain manufacturers who are notorious for that kind of issues, I'd put that on the back burner and deal with bug 1497963 and bug 1495743 first.

[1] If onTaskRemoved gets called before we're killed, we could check whether we currently have any downloads running - if yes and we're on Xiaomi, write a marker into the shard prefs. Then, the next time we launch we could ask the user to white-list us.

Comment 15

[Jan Henning [:JanH]]

(In reply to Jan Henning [:JanH] from comment #14)
> - As far as I can tell, launching Firefox after force stopping it during a
> download automatically resumes interrupted downloads. Maybe just bringing up
> Gecko without launching the full UI could already be enough to get
> interrupted downloads to resume then. If so, maybe we can detect the
> impending kill via onTaskRemoved() and then schedule a one-shot action if
> we're currently downloading something in order to restart Gecko in case the
> whole app process is terminated.

Encouraging news: If I force stop Firefox during a download and then bring up a custom tab, this is enough to get the download to resume, so the BrowserApp/browser.js UI indeed isn't required here.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

This issue is waiting on feedback from Andreas for user impact and to scope out the project and priority.

Comment 17

[Andreas Bovens [:abovens]]

I think we need more clarification about what this bug is about. 

- download notification still being displayed: that's intended behavior and thus wontfix
- notification action should display about:downloads: seems like this has been fixed as per Vlad's patch in comment 7.
- Xiaomi issue: seems very OS-specific and perhaps something that's not a priority to fix right now. We can downprioritize its importance, or even close as wontfix.

Comment 18

[Vlad Baicu]

(In reply to Andreas Bovens [:abovens] from comment #17)
> I think we need more clarification about what this bug is about. 
> 
> - download notification still being displayed: that's intended behavior and
> thus wontfix
> - notification action should display about:downloads: seems like this has
> been fixed as per Vlad's patch in comment 7.
> - Xiaomi issue: seems very OS-specific and perhaps something that's not a
> priority to fix right now. We can downprioritize its importance, or even
> close as wontfix.



(In reply to Jan Henning [:JanH] from comment #14)
> First of all we should sort out which bug is about what - currently this bug
> still claims to be about "Download progress notification still displayed
> after closing app on some devices" (and is being tracked for that reason),
> but because this is the intended behaviour the resolution should be WONTFIX.
> At the same time thought the discussion seems to have morphed into something
> different and this bug now has a patch for changing what happens when
> clicking on the notification, which isn't really related to neither the
> original issue nor bug 
> 1495743.

Marking this as wontfix.